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PREFACE 


A baseline Data Handling and Management System (DHMS) configuration and its 
estimated costs for hardware, software, and implementation are presented. The 
DHMS functions to automate the Tracking and Data Relay Satellite Systems (TDRSS) 
ground station’s (GS’s) activities, handling and controlling the forward and return 
link data that pass through the station. Two costing deltas for a modified Adaptive 
Ground Implemented Phased Array (AGIPA) are also provided. 

The DHMS preliminary systems engineering design is described in detail. 

Control of the DHMS is remotely located at a TDRS Operatons Control Center (OCC). 
Configuration costs are presented so that the dollar impact of changing the baseline 
system can be easily determined. The total estimated installed system cost is $8. 2 
million (M) (including the modified AGIPA concept). 

Augmentation of the baseline system to provide the capability for the OCC func- 
tions was studied and is discussed. The estimated cost of adding the OCC capability 
is $1. 36M. This plus the baseline cost totals $9.6M for an implemented baseline modi 
fied DHMS (MDHMS). 

In total, three MDHMS configurations were conceptually developed and priced, 
considering a variety of minicomputers and midicomputers produced by four manu- 
facturers. After considering the different t 5 T?es of computers, it was concluded that 
the MDHMS should have midi computers for computational power and system direction, 
and minicomputers (or interface processors) to perform the repetitive data handling 
activities (synchronizing or formatting user data, etc. ) under direction of the midi- 
computers. The estimated cost range for the full capability implemented MDHMS 
should not be more than $9.4M to $9. 8M, and a cost within this range is considered 
reasonable. 
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SECTION 1 - INTRODUCTION 


1.1 PURPOSE 

Automation of the Tracking and Data Relay Satellite System’s (TDRSS’s) ground 
station (GS) equipment is performed by the Data Handling and Management System (DHMS) 
In turn, the DHMS is controlled or directed by a TDRSS Operations Control Center (OCC). 

A two -phase study of the DHMS was performed. For Phase I it was initially 
assumed that the OCC was located remotely from the DHMS at the Goddard Space Flight 
Center (GSFC). During the Phase II study effort a composite system located at the GS 
was considered. The composite system, a modified DHMS (MDHMS), performs the 
functions of the DHMS and the OCC. 

As study results, three items of major significance for the GS implementation 
are presented in this final report. The report covers activity during the months of 
December 1972 through July 1973 and is submitted in fulfillment of Contract 
Number NAS5-22148 entitled "TDRSS Data Handling and Management System Study. " 

1.2 SCOPE 

A result of the first study phase is the description of an original baseline DHMS 
hardware/software preliminary system engineering design, also presented in a 
previous report. * A cost matrix for the baseline configuration is provided so that 
cost impacts of modifying the design can be assessed. 

Two accomplishments resulted from the second study phase. First, the cost 
impact is estimated for the situation where the OCC is collocated at the GS sharing 
the baseline DHMS equipment. Second, descriptions and costs are presented for 
three additional composite systems where each system is configured with computer 
hardware produced by a different manufacturer. Three MDHMS designs aie considered. 

*"TDRS Data Handling and Management System Study, DHMS Baseline Configuration, " 
Computer Sciences Corporation, Report R-4192-01, March 1973. 
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One design uses only minicomputers and is costed for two computer series. A second 
design is costed with a midicomputer series, and a third design uses a combination of 
midi and minicomputers. 

1.3 TDRSS BACKGROUND 

Incorporation of a TDRSS into the Spaceflight Tracking and Data Network (STDN) 
has been proposed by the GSFC to decrease the network’s future expenses while enhanc- 
ing its user services. These services are communication paths to and from the users' 
spacecraft and their Mission Control Centers (MCCs) and the generation of user- 
spacecraft tracking information. The communication paths enable the MCCs to com- 
mand and control their spacecraft and to receive spacecraft housekeeping and sensor 
telemetry data. Processed tracking data provide the MCCs with spacecraft position 
information. 

Most services for earth-orbiting spacecraft [having altitudes up to 5000 kilome- 
ters (km) ] can be supported by having them communicate with two geosynchronous 
Tracking and Data Relay Satellites (TDRSs), and the TDRSs require only one GS to 
handle the satellite-relayed users’ transmissions. It has been estimated that fewer 
STDN GSs will be required if the TDRSS is implemented and that the resulting TDRSS/ 
STDN configuration would cost less to operate than the unmodified STDN configuration. 
Furthermore, continuous communication with the users’ spacecraft can be maintained 
for about 85 percent of the low-altitude orbit times, a greater time duration than if 
only the basic STDN GSs were used for mission support. 

Therefore, it is reasonable to study the TDRSS in detail because of an expected 
network operational cost decrease and service improvement. As part of this study, CSC 
developed a baseline DHMS configuration that is one element of the TDRSS GS. The 
baseline DHMS design was then modified to also perform the functions that otherwise 
would be executed at a remotely located TDRSS OCC. Our final study effort was to 
develop three different composite system configurations (MDHMSs) using a different 
computer system in each configuration. Computer hardware/software costs for the 
four configurations are also provided. 
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The initial DHMS concept is put into perspective in Paragraph 1. 4. An overview 
of the MDHMS is presented in Paragraph 1.5. 

1.4 TDRSS INITIAL GROUND STATION OVERVIEW 

The TDRSS GS may be considered as an organization of four basic collocated sys- 
tems; the NASA Communications (NASCOM) Interface System, the DHMS, the Radio 
Frequency /Intermediate Frequency (RF/IF) System, and the Antenna System. Be- 
cause there are three planned TDRSs (two on-station and one in-orbit spare) the RFAF 
and Antenna Systems can be trisected. This is done, and TDRS No. 1 is specified as 
the East Satellite, TDRS No. 2 as the West Satellite, and TDRS No. 3 as the Backup 
Satellite, Figure 1-1 shows the GS organization block diagram and an interface to the 
GSFC (the ini tally assumed location of the TDRSS OCC). 

Communications via the TDRSS from the MCCs (forward link transmission) pass 
through the NASCOM interface to the DHMS. The DHMS routes the data messages to the 
addressed TDRS RF/IF system, from which they are sent to the proper antenna system, 
transmitted to the TDRS and, hence, relayed to the mission spacecraft. Telemetry 
data from the user spacecraft follow a reverse path (return link transmission) through 
the TDRSs to the GS NASCOM interface. Command and telemetry data between the 
TDRSs and the OCC complete the same GS procedures, but the TDRSs are the data 
receivers and transmitters. (The relay satellites use and generate the OCC data, they 
do not relay data for their own use. ) 

Having the general concept of information flow through the GS, we can now con- 
centrate on the heart of the station, the DHMS. Under normal operational conditions 
the DHMS; 

e Verifies MCC command transmissions and relays user-spacecraft commands 

1 2 

© Formats Low Data Rate (LDR) and Medium Data Rate (MDR) users T 
telemetry data 

1 LDR (500 to 10,000 bits per second, modified to an upper limit of 32 kbps). 

2 MDR (10 bps to 1 Mbps). 
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TDRSS - TRACKING AND DATA RELAY SATELLITE SYSTEM 
RF/IF - RADIO FREQUENCY/INTERMEDIATE FREQUENCY 
OCC - OPERATIONS CONTROL CENTER 


Figure 1-1. TDRSS Ground Station and Interface to GSFC 








© Formats users’ range and range rate tracking data 

e Relays TDRS commands and formats the relay satellite housekeeping data 
for the OCC 

o Automates and configures the GS equipment according to OCC commands 

© Monitors the GS equipment and link operational activities 

• Formats GS and forward/return link status data for the users and the OCC. 

In contingency situations, DHMS: 

© Enables activation of an onsite 2 -hour TDRS and GS equipment configuration 
schedule (requires GS operator intervention) 

© Provides use of onsite user command message storage for mission space- 
craft control (may require GS operator supervision) 

® Provides a disk data storage system with the capability to contain four 
1-Mbps and twenty 10-kbps user telemetry data streams for a 2 -hour 
reception period 

© Enables stored data to be transmitted to the MCCs for selected time intervals. 

All normal DHMS functions and the data storage and replay can be controlled by 
the TDRSS OCC; therefore, DHMS operators are not required. Maintenance personnel 
are required, however, and during DHMS contingencies they become operators to moni- 
tor the stored configuration schedule operation, and upon voice direction they manually 
activate user spacecraft command transmission from the stored spacecraft command 
data base. 

A design goal has been to eliminate single points of system failure by using redun- 
dant equipment. This has been accomplished in all but two areas, the LDR and MDR 
downlink systems’ data output switches to NASCOM. Each switch element can fail without 
affecting the remaining elements, however. This means that the failed element (handling 
data for one LDR or MDR channel) can be detected and replaced without affecting the 
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remaining data channels using the switches, it may be expected that a spare NASCOM 
link interface will be available (this depends on the system loading activity) in which 
case it can be set up and used to replace the link interface more quickly than the 
element can be replaced. 

Additionally, the disk data storage system is not duplicated, but it is modular. 
Therefore, one modular element (disk controller and data pack drives) can fail without 
affecting the remaining storage capacity. 

Ground station operation is independent of the system users’ data except in one 
case. (All TDRSS user activities are scheduled, however, ) This is the changeover in 
short-to-long (or long-to-short) pseudonoise (PN) code used on the MDR forward link 
channels. Control of the PN code length is enabled by examining the MDR users 1 com- 
mands. Upon recognition of a spacecraft command to accept a different code length, 
the DHMS control system' effects the forward link PN code changeover for the GS 
equipment. 

To facilitate design of the TDRSS GS it was segmented into 11 blocks, seven of 
which compose the DHMS; the four additional blocks include the remaining GS equip- 
ment. Section 2 is a description of the GS layout and the DHMS cost matrix. 

1. 5 MODIFIED DHMS 

All GS functions are automated by the DHMS control system. To incorporate the 
OCC functions into the GS systems we have chosen to modify the DHMS by having it 
directed by a composite control system (CCS). The MDHMS then performs the required 
DHMS and OCC functions in one composite hardware/software GS system. Therefore, 
the basic organization of the GS is still as shown in Figure 1-1, and the TDRSS OCC 
initially assumed to be located at the GSFC disappears from the figure. 

More hardware and software are required for the CCS than for the unmodified 
DHMS. However, the MDHMS performs not only those functions stated in Paragraph 
1.4, except relaying and formatting OCC data, but in addition, the MDHMS has complete 
control of the TDRSS because it: 
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® Schedules all TDRSS assets to support user spacecraft requirements 

e Generates and verifies TDRS commands 

e Generates and commands all TDKSS configuration changes 

0 Displays and monitors all TDRS housekeeping data 

© Develops contingency schedules (because of a TDRS failure, etc, ) 

© Provides satellite testing procedural capabilities 

© Has the capability to develop and maintain all operational and 
special TDRSS software. 

Three MDHMS conceptual designs were considered and configured with computer 
hardware systems produced by four manufacturers. Only one manufacturer’s computer 
equipment was used in any particular MDHMS design, however. 

Two configurations use only minicomputers. The Digital Equipment Corporation 
(DEC) PDP IX minicomputer series was used because it formed the computer equip- 
ment in the baseline DBMS, Therefore, the cost difference between the DHMS and the 
MDHMS due to adding the OCC functions can be compared to the cost of implementing 
a remotely located OCC. The minicomputer design MDHMS was also costed using 
Varian 73 computers. Therefore, a cost comparison is provided for the computer hard- 
ware produced by two minicomputer manufacturers. 

Only System Engineering Laboratories’ (SEL) SYSTEMS 86 midicomputers are used in 
a second MDHMS design to estimate the cost. The third design uses a combination of 
midicomputers and minicomputers, and it is costed with Xerox Corporation’s Sigma 9, 
Model 530, and System Control Units. 

Therefore MDHMS costs for three designs have been developed. The advantages 
and disadvantages of each configuration are weighed, and two major study conclusions 
are reached. The conclusions are: (1) that minicomputer systems should be used for 
the DHMS; and (2) that a combination of mini and midicomputer systems should be used 
for the MDHMS. 
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Section 12 presents diagrams and discussions of the MDHMSs. General descrip- 
tions of the necessary software for the OCC functions are provided. Note that orbit 
determination, attitude determination, and attitude or orbit maneuver planning programs 
necessary for the OCC operations are not included in the software descriptions. This 
set of software is assumed to exist at the GSFC available for use on the GSFC large 
scale IBM computers by request of the MDHMS operating personnel. These programs 
are not run in real-time as are most of those programs implemented at the TDRSS GS. 

1.6 STUDY SUMMARY 

The TDRSS GS study was begun in December 1972. Four reference documents 
were provided for background information, and additional study guidance was provided by 
the contract technical officer. 

A DHMS cost matrix, the primary study element, was to be provided by the end 
of February 1973. This was accomplished by presentations to the GSFC TDRSS study 
group. The first presentation, 30 January, provided an overview of our GS concept 
and the format in which the cost matrix was to be provided. Only some of the GS cost 
data were available at that time. The second presentation was scheduled for 15 February, 
but it was postponed until 22 February when a preliminary DHMS cost of $6. 8M was 
provided. System modifications were requested and a final cost matrix presentation 
was made on 7 March; the cost was $7.2M. 


^"TDRS Data Handling and Management Philosophy,” GSFC, October 1972. 

’’Tracking & Data Relay Satellite System Configuration & Tradeoff Study," Final Report 
(less cost data). North American Rockwell, October 1972. 

"Tracking and Data Relay Satellite System Configuration and Tradeoff Study,” Final 
Report (less cost data), Hughes Aircraft Company, September 1972. 

"Design Analysis Adaptive Ground Implemented Phase Array,” AIL/Cutler-Hammer, 
November 1971. 


1-8 



Three designs for the DHMS were considered during the first 3 study months. 

In general, off-the-shelf (OSH) hardware was used whenever possible to provide mini- 
mum uncertainty in the cost base. When special equipment was required, it was 
designed in reasonable detail to obtain an estimate for the procurement cost. 

Additionally, costs were developed for a different AGIPA system for the LDR 
users than was initially considered for the DHMS. The modified AGIPA system 
increases the previous DHMS estimated cost to $7. 9M. Of this total, approximately 
$1.7M is for computer, data storage, and console hardware, 

A quarterly progress report, issued in March 1973, completed the first study 
phase. The initial goal of the Phase II study was to determine the estimated costs for 
the MDHMS as an extension of the baseline DHMS developed during the Phase I effort. 
This goal was extended to include, if possible, computer costing estimates for hard- 
ware systems using different computers than were considered for the baseline DHMS. 
All goals were accomplished as documented in this report. 

A cost increase of $1.4M is estimated to implement the OCC functions in the 
baseline DHMS. However, the price of the computer equipment that was used in esti- 
mating the baseline DHMS was increased 10 percent by the manufacturer. Therefore, 
the composite baseline MDHMS cost is currently estimated at $9.6M [ ($7.9M + 

$0. 3M + $1.4M = $9.6M) (includes the modified AGIPA system)]. Of this total, the 
computer, data storage, and console hardware cost about $2,3M, The baseline MDHMS 
uses only the DEC PDP 11 series minicomputers. 

The second minicomputer MDHMS configuration hardware (computer, data 
storage, and console) using Varian series machines costs $2. 2M* Similar Hardware 
costs for the all-midieomputer system (uses SYSTEMS 86 computers) are $2.2M. 

This midicomputer system also has computer interface cards for LDR and MDR frame 
synchronizers and removes the need for hardware LDR and MDR user data switches* 
to the NASCOM communications channels. These factors reduce the baseline hardware 


*These are used in the baseline DHMS. 
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cost by about $0. 09M. The combination midi/minicomputer configuration using Xerox 
computers has similar hardware costs of I3.4M. 1 

Estimated prices for implemented MDHMSs include three cost categories: 
hardware, software, and implementation." For systems using only minicomputers 
the implementation cost is estimated as 90 percent of the total hardware cost. This 
percentage is reduced to 70 percent for the computer, data storage, and console hard- 
ware for the systems using midicomputers (90 percent is still applied for the remain- 
ing hardware). A reduction is justified because the midicomputer manufacturer 
integrates and system tests the composite hardware prior to delivery. Therefore the 
total MDHMS contractor's costs would be reduced. 

3 

All hardware costs are current, either supplied by the manufacturer or obtained 
from list prices (unless specially priced because off-the-shelf (OSH) equipment was 
not available), and reduced by original equipment manufactor (OEM) quantity or 
business volume discounts. Except for the DEC systems, the computer hardware 
systems for the MDHMS have been preliminarily reviewed for cost and technical 
completeness by the equipment manufacturers as a check on our designs and under- 
standing of the equipment pricing lists. The total software estimated for ail systems 
is $2.4M. Total implemented MDHMS estimated prices are: using DEC computers, 
$9.6M; using Varian computers, $9.5M; using SEL computers, $8.9M; and using 
Xerox computers, $11. 1M.^ 

It is not expected that any of the configurations developed in this study would be 
implemented exactly as described here. Modifications will be made as the TDRSS 
requirements are changed during the final TDRSS definition effort. Further, other 


Xerox personnel indicate that a change in their pricing structure is planned during 
August or September of this year that will reduce this cost. 

See Paragraph 2.5 for an explanation of this cost. . 

Except computer hardware costs in Section 2 that are to be increased. by 10 percent. 
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computer hardware can be used; however, we have developed information on three 
feasible MDHMS designs and priced them using four manufacturers' computer hard- 
ware. This information is more than adequate to define the preferred design and 
estimate its cost. 

Based on our current understanding of the MDHMS computational and data 
load, we recommend a system that uses midicomputers to perform the TDRSS com- 
putational requirements and to control and direct the TDRS and GS equipment, and 
uses minicomputers or computer interface processors^ to the maximum extent to 
relieve the midicomputers of repetitive user data handling activities. 

1.7 REPORT ORGANIZATION 

Section 2 provides a description of the TDRSS GS and its cost matrix. The 
baseline DHMS hardware, software, and implementation costs are presented in 
detail. A technical discussion of the major functional systems within the initial GS 
is presented in Sections 3 through 11. Section 12 discusses the composite (MDHMS) 
systems, presenting a tradeoff comparison of the three system configurations and 
costs. Descriptions of the three configurations for the all-minicomputer, all- 
midicomputer, and midi/minicomputer systems are provided, respectively, in 
Sections 13, 14, and 15. The new technology report is in Section 16. Appendices A 
and B document short study efforts performed during the reporting period. They 
consider functional availability and brief comments on the AGIPA components. 
Characteristics of the computer systems considered during the study are presented 
in Appendix C. 


1 Computer interface processors are special digital hardware circuits (interface 
cards) that perform one or a few preprogrammed functions under MDHMS computer 
control. 
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SECTION 2 - TDRSS GROUND STATION 


2.1 GENERAL 


This section presents the Phase I DHMS study results. Sections 3 through 11 pro- 
vide supporting technical information for the Phase I effort. 

A TDRSS functional GS layout is described. Functions are grouped into 11 major 
units. These are discussed, including elements outside of the DHMS costing area. It was 
necessary to lay out the total GS equipment configuration because of its interfaces through 
which the DHMS must work. 

Basic costing data are summarized. A hardware cost matrix is provided to show 
how the DHMS costs were developed. Matrix entries are made only for those units or 
subunits that are considered part of the DHMS. Software requirements are estimated 
separately in terms of manmonths of computer programming time. A dollar value for this 
effort is provided. An implementation cost 1 of 90 percent of the hardware cost is assumed. 
These three costs total $7.2M, A cost delta is also provided for a different AGIPA system. 


The majority of the DHMS hardware cost is for computers and their interfacing 

peripheral devices. For costing of the baseline system, Digital Equipment Corporation’s ^ 

\A ° 

(DEC’s) PDP 11 computer series was used. Computer system tradeoff studies w T ere n\ 

* 

not performed and, therefore, the PDP 11 systems are not necessarily the recom- ' 
mended GS computers. However, the computers are representative of the systems that 
would be considered for use, and the resulting hardware cost provides a valid bugetary 
estimate. 


2.2 GROUND STATION LAYOUT 

Figure 2-1 shows the GS layout developed for the study. Major units are numbered 
by '’tens” for identification as indicated in Table 2-1. Subunit identification numbers are 
allowed to range from 1 through 9, with the ’’tens" and "hundreds" digits determined by 
the unit number. An introductory description of the units follows. 


includes Installation, Integration, Engineering, Test, and Equipment Spares Costs. 
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Figure 2-1. TDRSS Ground Station Layout 
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Table 2-1. Unit Names and Identification Numbers 


Unit 

Number 

' 

Unit Name 

Cost Included for the DHMS 

Yes 

No 

Partially 

10 

NASCOM Interface System 


X 


20 

Control System 

X 



30 

Command Output and Verification System 

X 



40 

Command Uplink System 


X 


50 

Command Verification Downlink System 


X 


60 

Downlink System 


X 


70 

LDR Downlink System 

X 



80 

TDRS and Order Wire Sj^stem 



X 

- 90 

MDR/Shuttle Downlink System 



X 

100 

Consoles and Display System 

X 



110 

Test System 

X 
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2.2,1 NASCQM Interface System (Unit 10) 


All communications concerning the DHMS pass through the NASCOM interface sys- 
tem. Specific bandwidths or data rates have not been assumed except for the command 
and verification and the shuttle voice links. Only the voice links are assumed to be duplex; 
all other links are assumed to be simplex. 

User spacecraft commands, GS and TDRS configuration and antenna control com- 
mands, configuration schedules and updates (for onsite storage), GS-to-GSFC link status, 
and user commands for onsite storage are received over the digital command and verifica- 
tion links. Detection of a message received in error causes the message to be dropped, 
and reported to the sending element via a composite status link. Otherwise, the message 
is handled according to its contents. The sending element is notified that the message 
was properly received. A line rate of 56 kbps has been assumed from GSFC to the GS. 

The shuttle voice links are assumed to be standard analog telephone channels with 
a nominal bandwidth of 4 kHz. Characteristics of the remaining links have not been 
assumed, but they are considered to be simplex links that originate at the GS. 

Except for the composite status and two of the three range and range rate (R&R) 
links, only a single user's data are transmitted at one time on the simplex links. (Time 
division multiplex or message multiplexing is not performed in the DHMS. ) Data can be 
transferred from the DHMS to the NASCOM circuits at rates up to 500 kbps for all links 
except the MDR channels, where a 1-Mbps rate is provided. Therefore, constraints are 
not placed on the NASCOM network. The actual transfer rate is determined by the NASCOM 
data handling clock, and NASCOM is free to use message switching or line switching 
circuitry. 

A DHMS cost is not associated with Unit 10. The cost of the interface devices that 
are enabled to transfer data to NASCOM are included within the appropriate DHMS units. 
Section 3 provides a more detailed discussion of the NASCOM interface system. 
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2, 2. 2 Control System (Unit 20) 


Three primary subunit groupings make up the GS Control System, Unit 20. 

They are the processors, peripheral switching logic, and the peripheral Unibus systems. 
The four processors are PDP 11/45 Central Processing Units (CPUs) with a basic core 
memory, a CPU communication device (ASR 1 ), and a minimum of peripherals that 
enable the processors to be operated independently of other station equipment. Inter- 
computer channels are provided between all processors. 

The processors control the peripheral switching logic (Unibus multipole double- 
throw switches) that enable them to communicate with and control the peripheral Unibus 
systems. The switches are fail-safe devices (they also isolate a failed Unibus system 
from the processors). 

Each Uni bus system is redundant and each processor can communicate with at 
least one of the four different systems. The Unibus systems are connected to the 
computer controllable station equipment and computer-peripheral devices (disk storage, 
common core, printers, etc.) in each system. 

Redundant maintenance/ operator consoles are also connected to the Unibus system. 
The consoles enable any man-machine communication with the computer-controllable 
station equipment. 

All TDRS.OCC commands are executed by the control system as well as those 
resulting from use of the onsite consoles. User communications through the GS are 
handled by the control activity, as is the monitoring of the GS equipment. 

There are three special features of the control system. First, a test and backup 
processor provides the capability to perform maintenance programming with the actual 
GS peripheral devices not in use for active data control and handling. Therefore, new or 
modified software development does not require a redundant facility. Second, because of 
the redundant system elements, diagnostic operations and checkout can be performed 
without affecting normal station operation. 

^Automatic, send/receive teletype. 
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A third feature is that any two processors and half of the Unibus systems (one of 
each redundant system) could simultaneously fail without degrading the GS operations. 

A finite recovery time is associated with each failure, however (i. e., several seconds 
would be required for one processor to take over an online failed processor's operations 
or to activate a standby Unibus system). A minor exception is that only one LDR disk 
storage device is provided in the Unibus systems, and if the particular Unibus was down, 
LDR user data could not be recorded. 

Failure of three processors, however, degrades the station activities to just user 
and TDRS command handling and TDRS and GS equipment configuration control from the 
OCC. Established LDR and MDR channels would not be affected, and LDR handover 
operations from one TDRS to the other could be continued during the degraded operational 
period. 

Considerable design planning has gone into the baseline control system. A further 
description is provided in Section 4. 

2.2.3 Command Output and Verification System (Unit 30) 

Digital data communication between the DBMS and the station RF/IF systems is 
enabled by the command output and verification system (Unit 30) subunits. The second 
function of Unit 30 is to provide a return path for a ground check of the forward link data. 

Four primary subunits are involved with a switch connecting them to the uplink 
modulators in Unit 40 and demodulators in Unit 50. Three LDR command and verification 
buffer subunits provide one primary path for the forward LDR user link through TDRS 
No. 1 and No. 2, and a redundant (spare) subunit that can be connected to replace either 
primary path element. The MDR command and verification buffer subunits provide two 
primary forward MDR user links through each on-station TDRS, with a fifth unit that can 
be switched to replace any of the four primary elements. 

Only two shuttle command and verification buffers are provided. Each can be 
connected to either active relay satellite system. Four identical units are provided for 
the TDRS control uplinks, one for each active and the backup TDRS. The fourth 
element backs up any TDRS command and verification buffer subunit. 
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All forward link data are received from the control system except voice data. Shuttle 
voice is received from Unit 10, converted to a digital format (delta modulation), and multi- 
plexed with the uplinked digital commands in the shuttle subunit. 

Actual verification of the forward communications is not performed in Unit 30, 
but the demodulated data are handled from Unit 50 through the subunits. - They provide 
the interface to the control system where the verification is performed. (Note that 
uplinked voice is not digitally verified. It is converted to an analog format, and it could 
be returned to the speaker for verification, or it could be played to the onsite personnel. ) 

The forward link data ground loop design can be modified to perform the verifica- 
tion activities in the Unit 30 elements. Only detected bit errors would be input to the 
control system, reducing the processor load necessary to perform the verification. This 
modification would have a minor hardware cost impact, but the cost has not been developed. 

It is seen that single points of failure do not exist within Unit 30 because the 
modulator/demodulator switches are redundant, the subunits have a backup and either 
Unibus system 5 or 6 communicates with the command output and verification system. 
Additional system description is contained in Section 5. 

2. 2. 4 Units 40, 50 and 60 

The command uplink (forward) system (Unit 40), the command verification down- 
link system (Unit 50), and the downlink (return) system (Unit 60) contain the TDRS GS 
RF/IF and antenna systems. These units are not considered part of the DHMS, but they 
are included for completeness in the GS lajmut. Figure 2-1 shows some of the subunits 
in these systems. 

Certain control and monitoring points within the three units were considered, but 
not in detaii because specific configurations were not available. Control to and data from 
the points are assumed as part of the control system (Unit 20) activity. Therefore, an 
analog-to-digital converter and multiplexer are priced in the control system to handle 
the analog monitoring activity. Also, a digital multiplex monitor and control element is 
costed in Unit 90. It has the capability to address 256 points (8 bits) and input or output 
8 bits for each digital address. 
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Costing for signal transducers and conditioners and switches and switch- 
controllers for element control or monitoring within Units 40, 50, and 60 has not been 
included in the DHMS price. Section 6 includes some additional detail on the units. 

2.2.5 LDR Downlink System (Unit 70) 

Real-time spacecraft telemetry data {rates from 0,5 to 10 kbps) are handled in 
the LDR downlink (return) system, Unit 70. Provision for 20 users is made with 24 
separate AGIPA channels. This user support is developed by assuming that 20 channels 
are necessary for user spacecraft in view of either on-station TDRS. An additional four 
channels are provided to facilitate handover operations (relay support from one TDRS 
changing to support by the other active TDRS). The additional channels also provide 
redundancy when AGIPA channel failures occur. 

Analytical justification for the preceding assumptions is not available. It could very 
well be that a few more or less channels would provide the handover feature and backup 
capability with an acceptable probability of support. This investigation should be 
performed, but it is not planned for the current contract effort. 

The LDR channels are composed of four basic subunits. An AGIPA channel 
signal processor enables automated connection to IF modulated signals from TDRS No. 1 
or No. 2 and a test input. The processor receives eight signal streams from each input 
port that pass through computer-contx-olled variable phase and amplitude circuits, after 
which they are summed into one signal stream. Each input stream is relayed from 
four vertical and horizontal antenna elements located on the TDRSs. 

Data for each user are code division multiplexed (CDM). Thus the summed stream 
enters aPN code correlation circuit set for the particular user code. After PN code 
lock (the receiver code is in-phase with the spacecraft code) the second channel element, 
a PDP 11/05 computer is used to adjust the phase and amplitude circuits to maximize the 
received symbol stream power to interference power ratio. Polarization tracking is also 
accomplished in this process. Range and range rate circuits are in the signal processor. 
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The third channel subunit is a Viterbi decoder [assuming a rate \ (R = 3 ), 
constraint length 7 (K - 7), convolution code] that converts the received symbols to user 
data bits. The encoded data thus undergo forward error correction decreasing the bit 
error rate (BER) that would otherwise be obtained with respect to the received bit energy- 
to-noise-density ratio (E^/N q ). In the decoding process, the output bit rate is one-half 
of the input symbol rate. 

Provision is made in the AGIPA channel signal processor to handle four discrete 
bit rates within the 0. 5 to 10 kbps design limits. This is the costed circuitry. A future 
provision is to increase the handling range to 32 kbps and provide a continuously variable 
bit rate handling capability within the limits. This is discussed in Section 7. 

A fourth primary subunit is the LDR user NASCOM switch. Its purpose is to 
maintain a given user f s data on any one of 20 lines to Unit 10. Therefore, after a hand- 
over operation involving a second AGIPA channel acquiring the user’s data stream through 
the other relay satellite, the same NASCOM line can be used to provide data to a given 
user. 

Control action necessary to acquire a new user’s spacecraft data and to provide 
handover or failed channel replacement is directed by Unit 20. The control system 
also monitors the Unit 70 operations, receives the users’ R&R data from the AGIPA 

9 

channel computers, and records the users’ telemetry data when required. 

Much additional detail is necessary to understand the AGIPA system and how we 
have considered its implementation for costing purposes. After channel assignment to 
a user by the control system, the channel computer automates the AGIPA signal 
processor’s actions, provides frame synchronization for the data, formats it for 
NASCOM transmission, and essentially operates the channel independently from the 
remaining channels. Several other innovations were considered and the AGIPA system 
is further described in Section 7. ' . 

2.2.6 TDRS and Orderwire Downlink System (Unit 80) 

Unit 80 is considered as the simplest in the DHMS. The TDRS and orderwire 
downlink (return) system contains two identical redundant channels. Each receives 
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bit synchronized TDRS housekeeping telemetry data from the three TDRSs and digital 
event signals (on/off) from orderwires relayed by the active satellites. The telemetry 
data are frame synchronized by the channel computers (PDP 11/40 systems). Data are 
formatted for communication on three separate lines from each channel to the NASCOM 
interface for transmission to the TDRS OCC. The orderwire event signals are included 
in the formats. Similar formats or possibly preprocessed data formats are also sent 
to the control system. Unit 20 enables display of the data on the GS consoles. Because 
the control system processors can be programmed to uplink all stored satellite and space- 
craft commands, the control system under operator supervision can command the TDRSs 
in case of a contingent OCC-to-GS communication outage or of an OCC outage. Section 8 
provides a more detailed description of Unit 80. 

2.2.7 MDR/Shuttle Downlink System (Unit 90) 

\ 

The most expensive hardware element in the DHMS is the MDR/shuttle downlink 
(return) system, Unit 90. This results from using five PDP 11/45 systems to format the 
MDR users' data and a disk storage system for about 2 hours of incoming data from 
four 1-Mbps data sources. Less cost could be incurred by providing less data storage 
— or-using hardware data formatters and an instrumentation tape recording system for the 
data storage capability. This hardware option has not been costed; however, its use could 
increase operational expenses because of tape unit operators. 

Ten channels, each with the capability for handling up to 1-Mbps data rates, are 
provided. Because two MDR users can be handled by each active TDRS and each user can 
return a real-time and a delayed-time (recorder dump) data stream simultaneously, eight 
channels are necessary, and two channels are provided as a baekup. The redundant chan- 
nels also could be used to effect a minimum data perturbation during TDRS handover. 

Several subunits make up the DHMS elements in Unit 90. An analog switch provides 
the capability to connect any MDR channel to any of nine demodulators. Eight hard- 
decision and two soft -decision (3-bit quantization) bit synchronizers can receive the base- 
band digital data, shape it and derive symbol clock. Each bit synchronizer connects to one 
frame synchronizer that, in turn, can be. software connected to two PDP 11/45 systems. 
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The computers are programmed to time, and if required, status tag the data and 
format them into NASCOM messages. A digital switch is provided to connect any of the 
10 channels to any of eight NASCOM lines. This switch performs the same function 
as is provided by the LDR user NASCOM switch. 

There are two types of MDR channels. In effect, two dual -computer channels are 
provided to handle shuttle data, with the exception that only two soft-decision bit syn- 
chronizers, Viterbi decoders,* and delta voice dual -demodulators are supplied. These 
are channel Nos. 8 and 10 (using Unit 93 D and E computers, Figure 2-1). However, any 
of the 10 MDR channels can be used for data streams that require hard-decision bit synchro- 
nizers because the soft-decision units can be switched to provide hard-decision data to 
the frame synchronizer units. 

Note that there are two types of shuttle MDR systems that have been considered. 

The first system used a separate unit from the MDR frame synchronizer to effect voice 
data separation (demultiplex) from the return shuttle data stream. The current concept 
is to demultiplex the voice data by computer program that drives the delta-modulated 
return voice demodulators (digital -to -analog voice converters). 

Direction and monitoring of the MDR/shuttle data handling system is supplied by 
a schedule or real-time configuration command effected through the control system. 

Greater detail for Unit 90 is provided in Section 9. 

2.2.8 Consoles and Display System (Unit 100) 

There are three significant subunits in the console and display system, Unit 100, 

2 

These are the Go/No-Go Status Panel, the CRT Keyboard, and the Command Monitor 
Panel. 

Because a detailed design of the DHMS was not made, only some status panel ele- 
ments have been considered. In general, the panel would contain light activated event dis- 
plays showing the unit/subunit status and results of MDR channel readiness tests. An audio 

1 1 

Viterbi decoders for R = — K = 7 are priced in Unit 90, 

2 

Cathode ray tube. 
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alarm would alei’t maintenance personnel of unusual occurrences requiring immediate 
corrective action. 

The command panel provides ’thumb wheel” selection switches, enable switches, 
and push-button switches that would be used in activating the onsite configuration stored 
schedule and uplinking TDRS or user spacecraft commands by GS operators under voice 
direction from the TDRS OCC. A digital readout would be implemented so that command 
data could be manually verified before transmission. Also, manual override of normally 
automated GS activities would be controlled by the panel elements. 

Console operational, status, test, and any special devices would be driven by the 
control system, and automated communication by CRT keyboard use with the GS equipment 
would also be effected by Unit 20. Additional comment is provided in Section 10. 

2,2.9 Test System (Unit 110) 

Only minimal consideration has teen given to the test system (Unit 110) because a 
detailed DHMS design is required first. Two PCM simulator systems are priced and a 
modest allowance made for undefined test items and interfacing the simulators to the con- 
trol system. 

The simulator would be configured by Unit 20 to check out the MDR channels, 
injecting expected telemetry formats into the channels which would be programmed to 
verify DHMS throughput to the NASCOM interface. Testing would be of the go /no-go type 
requiring only a few seconds for channel checkout. A no-go response would cause the 
control system to alarm the maintenance personnel, and establish a redundant data 
handling link. In general, station turnaround would be expected to be accomplished, 
including TDRS reconfiguration, within six seconds (the time required to slew the 
satellite antenna through its maximum controllable range). 

Many additional equipment tests, plus test oscilloscopes, .frequency counters, etc., 
would be required for the GS test system. These items have not been costed. Section 11 
describes some test system actions in more detail. 
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2. 3 DBMS HARDWARE COST MATRIX 


Previous paragraphs have provided a detailed introduction to the envisioned TDRSS 
GS. Furthermore, the units considered to be in the DHMS were emphasized and an 
organizational structure (unit numbering system) was presented. 

A summary of the estimated hardware costs is presented in Table 2-2 for the DHMS 
units and subunits. Subunit costs are totaled to provide the unit cost. The total of the 
unit costs is $2, 855. 2K. The identification (ID) numbers can be used to locate the 
costed elements shown in Figure 2-1. 

To estimate the DHMS costs a preliminary and, in some instances, detailed equip- 
ment engineering design had to be completed. Technical details were considered. A 
cost matrix was developed during this effort to keep track of the results. 

Table 2-3 shows the cost matrix. Some column headings require explanation. 

Under ’’design approach” OSH stands for off-the-shelf, meaning that the particular unit 
or subunit could be purchased directly from a manufacturer. The abbreviation Sp stands 
for special, meaning that the equipment required special design and procurement. 

Under ’’basis for estimate" was entered an abbreviation representing the manufacturer 
or designer of the equipment. These are CSC for Computer Sciences Corporation, 

DEC for Digital Equipment Corporation, CC for California Computer Products, EMR 
for EMR Telemetry, MON for Monitor Systems, and finally IND meaning independent 
manufacturer (any of a group supplying the equipment for the estimated cost shown). The 
remaining column heading meanings are obvious. Note that additional entries in many 
columns would be made during a detailed GS system design. 

The most detailed designs were required to estimate the AGIPA (Unit 70) and the 
Unit 30 costs. The ground rules established and assumptions made were as follows. 

The AGIPA cost estimate does not attempt to verify the correctness of approach or the 
operational requirements of the hardware proposed or previously designed and fabricated 
by vendors under contract to NASA. To the greatest extent possible, the cost estimate 
is based on existing portions of hardware which have been delivered or demonstrated by 
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Table 2-2. DHMS Hardware Summary Costing 


Ground Station Unit 

Subunit 

ID 

Subunit 

Cost 

($K) 

Unit 

ID 

Unit 

Cost 

($K) 

I. NASCOM SYSTEM INTERFACE 



10 


A. Range and Range Rate Links 

' 1 




B. Status Link 





C. LDR Playback Link 

; jSlB 




D. Command and Verification Link 

14 




E. LDR Real-Time Links 

15 




F. TDRS Status and Data Link 

16 




G. MDR Data Links 

17 




H. Shuttle Voice Links 

18 




II. CONTROL SYSTEM 



20 

57 5.7 

A. Processor Systems 





1. Command and Configuration 

21 

34,0 



2. Monitor N 

22 

34. 0 



3. LDR/TDRS/R&R 

23 

34. 0 



4. Test and Backup 

24 

41.4 



B. Peripheral Unibus Switches 

25 

82.7 



C. Peripheral Systems 





1. Bus 1 and 2 

26 

203. 4 



2. Bus 3 and 4 

27 

77.0 



3. Bus 5 and 6 

28 

10.3 



4. Bus 7 and 8 

29 

58.9 



III. COMMAND OUTPUT AND 





VERIFICATION SYSTEM 



30 

165.4 

A. Uplink Command, Command 





Verification, and Buffers 





1. LDR Uplink and CVL 

31 

33,5 



2. MDR Uplink and CVL 

32 

59.0 



3. Shuttle Uplink and CVL 

33 

39. 3 



4. TDRS Uplink and CVL 

34 

23.5 



B. Modulator and Demodulator 





Switches 

35 

10. 1 



IV. COMMAND UPLINK SYSTEM 



40 


A. Ku Band Uplink Subsystem 





B. VHF Uplink Subsystem 
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Table 2-2. DHMS Hardware Summary Costing (Continued) 


Ground Station Unit 

Subunit 

ID 

Subunit 

Cost 

($K) 

Unit 

ID 

Unit 

Cost 

($K) 

V. 

COMMAND VERIFICATION 






DOWNLINK SYSTEM 



50 



A. 

Ku Downlink (Command 







Verification) 






B, 

VHF Downlink (Command 







Verification) 





VI. 

DOWNLINK SYSTEM 



60 



A. 

Antenna 






B. 

Dipl ex er 






C. 

Down Converters and Receivers 






D. 

Splitters 






E. 

Mixers 






F. 

Microwave Link 





VII. 

LDR DOWNLINK SYSTEM 



70 

S81. 5 


A. 

Downlink Subsystem 







1. Switch 

71 

12. 1 





2. AGIPA Interface 

72 

78. 7 




B. 

AGIPA Subsystem (24 channels) 







1. AGIPA Hardware 

73 

680. 0 





2. AGIPA Minicomputers 

74 

110.7 



VIII. 

TDRS AND 0. W. DOWNLINK SYSTEM 



80 

66. 1 


A. 

TDRS Downlink Subsystem 







1. Receiver 

81 






2. Demodulator 

82 






3. Bit Synchronizer 

83 

18. 0 





4. Computer Interface 

84 

12. 0 




B. 

Order Wire Downlink Subsystem 







1. Detectors 

85 






2. Computer Interface 

86 

1. 8 




C. 

PDP 11/40 Computer Subsystem 

87 

34. 3 
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Table 2-2„ DHMS Hardware Summary Costing (Continued) 




Subunit 


Unit 


Subunit 

Cost 

Unit 

Cost 

Ground Station Unit 

ID 

($K) 

ID 

($K> 

IX. MDR/SHUTTLE DOWNLINK SYSTEM 

! 


90 

1006.5 

A. Downlink Subsystem 

91 

(285.0) 



1. Receivers 

91-1 




2. Demodulators 

91-2 




3. MDR R&R 

91-3 




4. Analog Switch 

91-4 

8.0 



5. Bit Synchronizer (hard) 

91-5 

48. 0 



6. Bit Synchronizer (soft) 

91-6 

17. 0 



7. Frame Synchronizer 

91-7 

. 70. 0 



8. Interface Logic 

91-8 

142. 0 



B. Shuttle Subsystem 

92 

34.6 



C. MDR Minicomputer Subsystem 

93 

678. 1 



(C 1 ) Less Data Storage and Switches 

(93’) 

(247. 2) 



(C ,f ) Storage and Switches 

(93”) 

(430.9) 



D. MDR Data Output to NASCOM 

94 

8. 8 



X. CONSOLES AND DISPLAY SYSTEM 



100 

60. 0 

A. Console 

101 

24.0 



B. Command Control Panel 

102 

21.0 



C. GO/NO-GO Status Panel 

103 

15. 0 



XI. TEST SYSTEM 



110 

100,0 

A. Simulator 

111 

42. 0 



B. Interface and Test Equipment 





Allowance 

112 

58. 0 



TOTAL DHMS HARDWARE COST ESTIMATE 


$2, 855, 2K 
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Table 2-3. Hardware Cost Matrix 


1. NASCOM INTERFACE SYSTEM 
{Unit 10) 

Unit 

I.D. 

Units 

Design 

Ap- 

Cost 

Estimate 

Basis 

tor 

Est. 

Configuration 

Control 

Monitoring 

Parameters 

Control Criteria 

Notes 

Rcq f d 

Backup 



5Bfl 

A. Range and Range Rate Links 


1 


1 

1 

1 

1 

Control output links for 
MDR and LDR users, also 
control MDIt R&R sample 
rate. 

Line active, 
yes/n o y , , 

Polynomial Encoder/ 
Decoder (PED) 

(1 user) MDR (1.0 a 3 mp leu/ second) 
2. 4 kbps, simplex 

■ 








Tl 

(20 users) LDR (1 sample /second 
each) 2.4 kbps, simplex 




■ 





" 

(4 users) MDR (1 sample/second 
each) 1.2 kbps, simplex 

B. Ground station equipment 

operational and link composite 
status link 

12 

■ 

■ 

■ 

1 


■ 

Data out ol link 1 or 2 to 
TDRSS OCC and users' 
MCCS 



(TORS/ MDR/ LDR users) 
4,8 kbps, simplex 

C. LDR recorded data playback 
link 

13 

■ 


■ 

■ 



Line number, mission 
number, time interval 

" 

11 

{1 to 20 users) NASCOM selects 
rate, simplex 

D. Command and command 
verification link 

14 

— 

2 

1 


— 


■ 


■■ 

11 

SG kbps, simplex 

1 

15 

20 


■ 




User data ready /not ready 

" 

" 

NASCOM selects rate, up to 
500 kbps transfer rate, simplex 

F, TORS telemetry status and data 
links 

16 

■ 


■ 

■ 



Mission status of each 
TDRS 

" 


M 

G. MDR telemetry data links 

' 

17 

■ 



1 


■ 

Line number, mission 
number, real-time/ 
playback 



NASCOM selects rate, up to 
1 Mbps transfer rate, Rimplcx 

It. Shuttle voice links 

18 


■ 


■ 



Schedule 

■’ 

Voice present 

Duplex voice links 
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i 

i— * 

oo 



The monitor system is tisud ;ik 
htichup tu processor 2! onlv il 
processor M is down. 








Table 2-3 


Hardware Cost Matrix (Continued) 



to 

i 

CD 



ffl 



Cost 

Estimate 

Basis 

Cor 

list. 

Configu ration 
Control 

Monitoring 

Parameters 

Control Criteria 

Notes 


Itcq'il 


m 






:i. Ullt/TOHS/itiR Processor 

2d 

, 

] 


OSH 

($K) 

(SKI 

34.0 

DEC 

1. Command each AG1PA 
computer channel to a user 
data stream on either 
TDRS l or 2. 

2. Control (ho following for 
each AG1PA channel: 

a, TORS user number 

b. Bit rate 

e. PM sctpicncc 

3. Command formats for 
storage of LOR and TDRS 
data. 

4. Command format for 
status of TDRS to monitor 
system. 

5. Peripheral Unlbus Con- 
trol: 

Prime - P3 

Backup - P2, P4, P5. PI 

1, Status ti data 
lock on each LDK 
assigned channel 
and on each TDRS 
spacecraft. 

1. Program to schedule 
each user data stream as 
It goes from TDRS 1 to 
TDRS 2 and then to no data 
during back orbit intervals 

1. LDR/TDRS/Ii&R processor con- 
. Irol assignment of each AGIPA 

computer channel. Also, each 
TDRS computer processor. 

2. Provides storage in block form 
for specified LDK and TDRS data. 

3. Output TDRS Status to monitor 
system for display. 

•1. Provide outputs (o NASCOM of 
Tints status amt playback data for 
LDR and TDRS users. 

5. Process and output range ■■ range 
rate (Rfr It) for I.DH and M l)U users. 
(1, System con be used as backup to 
Command & Configuration Processo 
oniy il processor 21 and 24 fail. 

4. Test & Backup Processor 

(Add Memory Management 
Unit and KiK of core) 

24 

1 

■ 

OSH 

1 

■ 

DEC 

1. Peripheral Unibus Con- 
trol; 

Prime - P2, PI, PC, Pfi 
Backup - PI, P7 



This processor is used for system 
lest, program development and ns 
backup to processor 21 , 23, and 22 
(in that order). 

IS. Peripheral Switching Logic 

25 

12 

1 



S2, 7 

DEC 




Unibus Switches are used to connect 
any of (he computer processor to 
the required peripheral Unibus 
lines. 
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Table 2-3. Hardware Cost Matrix (Continued) 


1. CONTROL SYSTEM (Unit 20) 


C. Peripheral Unibus Systems 

1. Peripheral UnibUB 1 & 2 

a. Paper Tape Reader Punch 

b. Line Printers 

e. CAL/COM Interface Disk 
Controller 

d. Disk (CAL/COM) 

e. Console display controller 

f. Program & Verification 
Interface for all MDR sys. 

g. MDR minicomputer inter- 
face units (DRUG) 

h. Configuration control 
memory (liSK) 

l. Tape drivers 


Peripheral Unities 3 and 1 

(LIMt/IUR/TDlIK) 

a. CAL/COM Interface Disk 
Controllers 

b. Disk 

c. LOR NASCOM Switch 
(DRI2C) 

d. LOU (AC11PA) n/or> 
Computer I/O (DRUB) 

e. TORS U/dO computer 
interface (DRUC) 

f. MDR Range & Range Rate 
(iMtllC) 

g. LIJR/TDRS NASCOM links 
(Diumi 

h. f!4 It NASCOM interface 
links (DRUB) 

l. Unfhus extender (DBILA) 


Cost 

Estimate 


Configuration 

Control 


Monitoring 

Parameters 


Control Criteria 


Jteq'd Backup 





DEC Peripheral Unibus 1 is 

>EC controlled In prime mode 

by: 

;C 1. Command S Configura- 
te lion processor, 

DEC 

In backup mode by: 

1. Test & Backup Processor. 

DEC 2, LDH/TDRS/R4R Procei sor 

DEC Peripheral Uni bus 2 is 

controlled In Prime Mode: 

DEC 1. Test & backup system 

DEC in backup mode by: 

3, Command & Configura- 
tion processor, 

2. Monitor processor. 


Peripheral Unlbus .1 fs con- 
trolled In prime mode by: 

1. LDR/TDRS/RS H p re- 
el C cessor In backup mode by: 
CC 1. Monitor processor 

DEC Peripheral Unibus 1 is con- 
trolled In prime mode by: 
DEC L. Test & Backup proccsso: 
in the backup mode by: 

DEC 1 . LOR/TURS/R& II process 


6. 0 DEC 
3. 3 DEC 



Peripheral Unlbus 1 Is used to 
support the Command & Configura- 
tion functions. 

Peripheral Unlbus 2 is used to 
support the Test & Backup functions . 


Peripheral Unlbus 3 and >! are used 
to support tin: functions of the 
LDR/T DRS/Kftit processor. 


Interface cost in AGJPA cost. 
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Table 2-3. Hardware Cost Matrix (Continued) 


tl. CONTROL SYSTEM {Unit 20) 


Unit 
I. D. 


Rctj'd Hookup 


Dust pi 
Ap- 
proach 


Coot 

Estimate 


Unit Total 


Basis 

for 

Est. 


Configuration 

Control 


Monitoring 

Parameters 


Control Criteria 


to 

I 

to 

H-t 


Peripheral Unibus 5 and 6 

{Communications i 

a. Command & Command 
Verification. Uplink Unibus 
Interface 

b. Command & Command 
Verification Interrupt 
Logic Units 

c. Command & Control 
NASCOM interfaces 
(DPil-DCj 

d. NASCOM Switch 

e. Composite status interface 
(DRII-Cl 


■ASK) 


<$K) 
10. 3 


Sp 


OSH 


OSH 

Sp 


OSH 


1.5 

3.0 


5.9 
3, 0 


DEC 

CSC 


DEC 


Peripheral Unlbus 5 is con 
trolled in prime mode by; 

1, Command & Configura- 
tion processor. 

In backup mode by; 

1, Monitor processor 

2. LIJR/TDRS/H8-R 

Peripheral Unlbus G is eon 
trolled in prime mode by; 

1. Test & baeltup processo^ 

tn backup mode by; 

1. Command & Configura- 
ilon processor. 

2. LDR/TDRS/ 1U R 


Peripheral Unlbus 5 and >> are used 
to support the functions of the com- 
mand and configu ration processor. 

In cost of Unit 30 


Peripheral Unlbus 7 and 8 
(Monitor) 

. n, CIU' Controllers 

b. CRT Hard Copier 

c. Console Drivers 

d. Status inputs (DRIICj 
c. Unlbut Switch {DT03) 

f, EMR taterfacc card 

g. A-to-1) Converter 6 Analogj 
Multiplexer (EMR 2707) 

‘ Handle 250 analog Items 


OSH 

OSH 

Sp 

osn 

OSH 


2.7 

4.0 

5.0 
0. 33 

0 . 9 

3.5 


58.9 

10. 8 
6.0 
10. 0 
0. 7 
G. 9 
1.5 


DEC 

IND 

CSC 

DEC 

EMR 


Peripheral llnibtis 7 Is 
controlled in prime mode b(r 
1. Monitor processor in 
backup mode by; 

1. Test 8 backup processo 

Peripheral Unibus 8 is 
controlled in prime mode bjv 
1. Test & backup processo 

in backup mode hy: 

1. Monitor processor. 


Peripheral Unlbus 7 and H are used 
to support functions of the monitor 
processor. 














Table 2-3. Hardware Cost Matrix (Continued) 



to 

i 

to 

to 


III. COMMAND OUTPUT AND 
VERIFICATION SYSTEM 
(Unit 3'l ) 

Unit 

C.U. 

. . 

Units 

Design 

Ap- 

proach 

Cost 

Estimate 

Basis 

Cor 

list. 

Configuration 

Control 

Monitoring 

Parameters 

Control Criteria 

Vi 

Red'd 

Backup 

Unit 

Total 






($K) 

($K) 






A. Uplink Commune!, Command 












Verification and Buffers 












1. LDB Uplink and CVL Module 

31 

2 

1 

sp 

11.2 

33. 5 

CSC 


Activity buffer status 

Loss of verification 











CVL Sync (16) 



2. MDIt U|>link and CVL Module 

32 

4 

1 

Sp 

11. 8 

59.0 

CSC 

Long code/' short code 

" 

" 


3. Shuttle Uplink and CVL Module 

33 

1 

1 

Sp 

19.6 

39,3 

CSC 

Lflng code/ short code 

- 

" 


4 .- TDBS Uplink and CVL Module 

34 

3 

1 

Sp 

5,9 

23.5 

CSC 


Buffer status (16) 

• " 


B. Modulator (Uplink) and Deniodu- 

35 

1 

1 

Sp 

5.1 

10. 1 

CSC 

Modulator and 

Program 

Loss of verification on a 


Jo tor (CVL) Switches 








demodulator channel 

verification (13) 

channel or modulator 










configuration (13) 




TV. COMMAND UPLINK SYSTK M 


Units 

Design 

Cost 

Basis 

Configuration 




(Unit III) 

Unit 

I. D. 



Ap- 

tiSli 

rn ale 

for 

Est. 

Control 

Parameters 

Control Criteria 

Notes 



Reel'd 

Backup 


Unit 

Total 






A. Xu Band Uplink Subsystem 












1. Command Modulator' 

41 

8 

8 









2. Mixers 

42 

8 

S 









11. Combiner 

43 

2 

2 









4. Up Convertor 

44 

2 

2 









H. Tranimilter 

4D 

2 

2 









fl. Diplexer 

46 

2 

2 





Select (2) 

Power out level (8) 

Power level limit 


7. Ku Antenna 

47 

2 

• 0 









B. VJI F Uplink Subsystem 












! X. Moclulat or/Tran smitten 

48 

1 

1 





Select (2) 

Power out level (8) 

Power level limit 


2. VT1 F Antenna 

48 

1 

0 







- 
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Table 2-3. Hardware Cost Matrix (Continued) 


V. COMMAND VKW ITCAT1GN 
DOWNLINK SYSTEM (Unit 30f 

Unit 

I.D. 

Units 

Design 

Ap- 

Cost 

Estimate 

Baals 

for 

Configuration 

Control 

Monitoring 

Parameters 

Control Criteria 

— — — 

Notes 

Rcti’d 

Backup 


Unit 

Total 


Ku Downlink 
(Command Verification) 

1. Down Convertor 

2. Splitters 

3. Mixers 

•f. IX 1 modulators, Detectors 

r,i 

52 

53 

54 

2 

2 

fi 

S 

0 

(J 

<3 

0 


<$K) 

(3K) 


► V' 7 - ’’ 

AGC level (8) 



«. VHP Downlink 

(Command Verification) 

1. Command Verification 
Receive rfi/De modulator 

55 

I 

0 






AGC level (8) 



VI, DOWNLINK SYSTEM (Unit BO) 

Unit 

I.D, 

Units 

Design 

Ap- 

proach 

Cost 

Estimate 

Baals 

for 

Est. 

Configuration 

Control 

Monitoring 

Parameters 

Control Criteria 

Notes 

lleti’rl 


Unit 

Total 

A. Antenna (In Unit tot 

til 

2 



(SK) 

<SK> 


Select (4). each 

Status on 12 bits, 
each 



H. Diplexer (in Unit 10) 

02 

2 

2 





Select (2) 


Losa of all data 


Down Converters and Receivers 

G3 

2 

2 





Select (2), select mode 
and bit rate (S), set 
frequency (8). and 
bandwidth (4) 

Phase lock loop 
AGC level (8) 
Lock display (2) 

Mode required, bit rate 
limit level and rate limit 
and data loss 


n. SplUiors 

04 

2 

2 





Select (2) 

On line/off lino (2) 

Power level limits 


K. Mixers 
l. LOR 

i 2. ill DR /.Shuttle 
it. TORS 
4. Order Wire 

05 

05-1 

05-2 

35-3 

'5-4 

2 

8 

3 

2 

1 

3 

3 

2 





Select (2) 

Frequency Tune (JB) 
Select (4) 

Frequency Tune (16) 
Select (3) 

Frequency Tune (1(3) 
Select (2) 

•Signal level (8) 
Diode current (K) 

Signal level limit 
Diode current limit 


F. Microwave tank (In Unit 10. !>tl 
and (it)) 

5-5 

3 

3 





Select ft), each 

Status on 12 bits, 
each 

| 
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Table 2-3. Hardware Cost Matrix (Continued) 


VII. I. Hit DOWNLINK SYSTEM 
(Unit 70) 

Unit 

I.D. 

Units 

Design 

Ap- 

Cost 

Estimate 

Basis 

for 

Configuration 

Control 

Monitoring 

Parameters 

Control Criteria 

Notes 


Ileq 'tl 

iblckup 


Unit 

Total 

1st. 




A. Dawnl i nk ; Rubsy stem 





(SK) 

<SK] 






1. Switch 

71 

1 

0 

Sp . 

12. 1 

12.1 

CSC 

Select 20 of 24 computer 
outputs for transmission 
to NASCOM 

Data set ready 
Clear to send 

Loss of control line 

Includes DRllC for control 

2. AGIPA Interface Logic 

72 

2H 

4 

OSII 

3.3 

7S. 7 

DEC 




Connects AGIPA to control system 
and signal processor to computer 

D, AGIPA Subsystem 








Dit rate (2) 

PN sequence (5) 
AGIPA dements (16) 

AGC level (SI 
Program verify 



1. AGIPA Hardware (21 chrtmu.dK) 

73 

20 

4 

Sp 

2S. 3 

GfiO, 0 

CSC 





2. AGl PA Minicomputers 

74 

20 

4 

OSII 

4. 6 

110. 7 

DEC 




PDP- 11/05 computer used as 
interface to each AGIPA channel. 
Each channel performs the following 
functions- 

' 

• 

i 

. 











a. Frame synchronization of data 
and NASCOM blocking 

1), Controls pointing 

c. Control AGIPA elements 

d. Programs PN generator 

0. Programs input switch 

f. Programs bit rate 

g. Outputs data to NASCOM 

h. Takes status of system 

1. I/O control with 1.1)11 prime 
computer system 

j. Sonets [(fill formatted data to 
control system. 
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Table 2-3. Hardware Cost Matrix (Continued) 


nil. THUS AND O.W. DOWNLINK 
SYSTEM (Unit HO) 

Unit 

I.J>. 

Units 

Design 

Ap- 

Cost 

Estimate 

Basts 

for 

list. 

Configuration 

Control 

Monitoring 

Parameters 

Control Criteria 

Notes 

Req’d 

Backup 


iiiii t 

Total 





A. TORS llownl ink Subsystem 





($K) 

($K> 



ACC level (8) 
Lock display (2) 

Love! and rate limits 
Data loss 


1. Receiver 

HI 







Set frequency (8) 
Bandwidth (4) 
Mode (4) 




2. Demodulators 

82 







Select (2) 

PLL 

Noise level (8) 
DC level (8j 

Mode required, bit rate 
limit, noise level and 
DC limits 


Bit .Synchronization 

82 

a 

2 

OSH 

3.0 

18.0 

MON 

Hate (8) 

Loop bandwidth 

DC level (8) 
•Sync error (8) 



4. Minicomputer interface Logie 

84 

r 

6 

Sp 

1,0 

12.0 

CSC 




Includes niillC Cards 

H. Order Wire Downlink Subsystem 












1. Detectors 

ar> 











2. Minicomputer Interface Logic 

HO 

i 

1 

Sp 

0.0 

1.8 

esc 





C. PDI* 11/41) Computer Kubsyslcm 
(18k core, clock, Ijoott 
Includes NASC’OM anti Control 
Interface 

87 

i 

1 

OSH 

3 7. 7 

.84. .7 

DLL' 




Three TORS data linos front each 
computer to NASCOM mtei.f;ret» 
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Table 2-3. Hardware Cost Matrix (Continued) 


IX. MDR/SHl'TTLK IX WN LINK 
SYSTEM (Unit 00) 

Unit 

MX 

Units 

Design 

Ap- 

proach 

Cost 

Estimate 

Basis 

for 

fist* 

Conflgu ration 
Control 

Monitoring 

Parameters 

Control Criteria 

Notes 

Kcq’d 

Backup 

Unit 

Total 





A. Downlink Subsystem 
1 . Hcceivers 

91 

91-1 

8 

1 


($K) 

($K) 






2. Demodulator 

91-2 

H 

1 









3. M 11 H H&R 

91-3 

8 

. 1 









4. Analog Switch 

91-4 

8 

2 

Sp 

0.8 

8.0 

CSC 

Select 1 of 9 modulators (4‘ 

Program verify 

No verification 


0. Bit Synch 

91-5 

7 

1 

OSH 

6.0 

48.0 

MON 

Bit rate (19), Loop 
Bandwidth (2). Code (3). 
Source (3), Det Pol (2) 

Loss of signal, 
DC offset, sync, 
power on 

Mss of sync or signal, 
excessive offset, loss 
of power 

Monitor Model 317 

(i. Soft Decision Bit Sync 

91-6 

1 

1 

OSH 

8.5 

17. 0 

MON 

" 

-> 

M 

Monitor Model 330 

7, Frame Synch rnnizer 

91-7 

8 

2 

OSH 

7. 0 

70.0 

MON 

Frame sync pattern (33) 
Frame length (6) 

Sync strategy ( 15) 

Sync status poweron 

Loss of power, toss of 
sync 

Monitor Model 431 

8. Interface Logic 

91-5 

1 

1 

Sp 

28.0 

142.0 

CSC 

Switch Viterbi decoder to 
frame sync 

Digital line status, 
program verify 

Open or shorted digital 
signal paths; no program 
verification 

Includes digital monitor ami 
cont rot circuits 

B. Shuttle Subsystem 

92 

1 

1 


17. 3 

34. f> 

CSC 


Power on, data 
activity 


Includes high hit rale 

It = J, K = 7 Viterbi decoder 

C. MDfl Minicomputer Subsystem 

93 











1. LA30 DEC Writer 

93-1 

4 

1 

OSH 

-- 

— 

DEC 




Cost included with PDP-ll / 45 

2. MMU(KTn-l)) 

93-2 

4 

1 

OSH 

3. 2 

10 . 0 

DEC 





.3. Cinch 

93-3 

4 

1 

OSH 

0.5 

2. 5 

DEC 




Programmable real-time clock 

4. Boot (32 word read-only diode 
memory) 

93-4 

4 

1 

OS1I 

0. 3 

1.5 

DEC 





5, 3-Hh Core Memory 

93-5 

•1 

1 

OSH 

12. 1 

00. 7 

DEC 





: ti. Control System 

\ Peripheral Interfaces for 

' Unihus S! and >2 

93-5 

R 

2 

OSH 

0. 33 

3. r 

DEC 




DR11-C interface units 

7. CPC 1B45 

93-7 

4 

i 

OSH 

16. 0 

80. ( 

DEC 





r . cpu u/on 

93-S 

* 4 

i 

OS1I 

3. 4 

17- ( 

DEC 





9. Solid State Control ('nit 

93-9 

4 

i 

OSH 

i.r> 

8. ( 

DEC 
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Table 2-3. Hardware Cost Matrix (Continued) 


IX. MDR/SHL’TTI.F. DOVVNUNK 
SYSTEM (Unit 90) 


Units 

RtqM I Backup 


Cost 

Estimate 
Unit | Total 


Configuration 

Control 


Monitoring 

Parameters 


Control Criteria 



C. MDR Minicomputer Subsystem 
(Continued) 

lfl. fik MOS Memories 

93-10 

11 . ftk Core Memory for Unibus #2 

93 - n 1 

12. MDft Storage System 

a. CAL/COM Controllers 

93-12 

h. Disk Pa its ! 

9 3-13 

ID. Peripheral t'nihus Storage 

93- 14 

System Switch 




($K) 

($K) 


8.5 

4 2. B 

DEC 

3. 1 

15.3 

DEC 

20.0 

104. 0 

CC 

17.9 

285.6 

CC 

0.9 

41.3 

DEC 



MSI 1 -BP solid state memory 
MM11-C core memory 

Each storage system having 
capability for 8()(>M bytes of data 

OT03 Unibus Switches 


0. MDR Data Ouij m l Switch 
io K A SCUM 



Selects of ID computer 
outputs for transmission 
to NASCOM 


Clear to send 
Data set ready 




Table 2-3. Hardware Cost Matrix (Concluded) 


BE 


fcH K, 

Co r 


UJ 

|; 

CONSOLES AND nlSl*Ij\Y 
^ SYSTEM (Unit 100) 

■a 

Unit 

t.I). 

Units 

Design 

Aj;- 

Cost 

Estimate. 

T~~ 

Basts 

Cor 

Configuration 

Control 

Monitoring 

Parameters 

Control Criteria 

Notes 

Reel'd 

Backup 


Unit 

Total 

t.st* 

t 

k 

g 

A. Console 

101 

2 

1 

Sp 

(SK) 

8.0 

(SK> 
21. ( 

CSC 




Two consoles for normal 
operations and one console for 
test system , Each console having 
a command control panel, CUT 
display with Keyboard ami a 
GO/NO-CO status panel. 

n. Command Control Panel 

102 

2 

1 

Sp 

7. 1) 

21. 0 

CSC 

Inputs from control systen 
peripherals ff] and 02 




c. GO /.NO- GO Status Panel 

103 

2 

l 

Sp 

0.0 

15. 0 

CSC 

inputs from control system 
peripherals 03, 02, #7 
and 08 




XI. TEST SYSTEM (Unit 1 1 0 > 

. 

Unit 
1. 1). 

Units 

Design 
Ap- 
p roach 

Cost 

Estimate 

Basis 

for 

Hat. 

Configuration 

Control 

Monitoring 
Pa ram etors 

Control Criteria 

Notes 

Key'd 

Backup 

Unit 

Total 

A, Simulator 

/ 

11! 

1 

1 

OSH 

<$K) 

21.0 

( SKI 
12.0 

MON 

Controlled from 
peripheral Unibus 01 and 
for S2 



Simulation system to provide for: 

a. Link readiness checks 
1). Simulation of each type of 
telemetry data (LDR, MDB, 
shuttle or TDBSi 


0. Allowance Cor Interface and 
Additional Test Devices 

i 

112 


1 

Sp 

20. 0 

58. 0 








the vendors (computers, Viterbi decoders). Whore hardware does not currently exist, 
the estimate is based on a detailed preliminary design configuration capable of meeting 
the available or known performance requirements (channel signal processor). 

The following assumptions were made for hardware to be specially designed: 

© The design,, fabrication and testing of the processor will be accomplished by 
a vendor having available personnel and facilities to execute the job in a 
competent manner and who has demonstrated experience and competence in 
similar or related equipment. 

© The design will be completed using only current technology and components, 

© The scheduled time for completion of the work will be realistic in terms 

of the effort to be undertaken and that no premium labor or other cost penalties 
will be incurred as a result of schedule requirements. 

© The AGIPA processor will consist of a single unique equipment procurement 
(i. e. , there will be no "production’ 1 type follow-on) so that the design docu- 
mentation, administrative controls and other factors will be representative of 
a custom product activity. 

— ® The equipment to be delivered will be of sound design and construction, repre- 

sentative of commercial-grade instrumentation designed for use by skilled, 
competent technical personnel. 

© The equipment is designed to be operated continuously in a clean, sheltered 
environment having maximum temperature extremes of 0°C and +50°C and 
actual operating conditions of 25° + 5°C. 

0 Documentation and reports to be provided by the vendor conform to standard 
commercial practices. The level and detail of such documentation is adequate 
to permit maintenance and repair and operation by reasonably skilled technicians. 

e Warrantee on the equipment is for 1 year from date of delivery and is limited 
to repair or replacement of defective components and that no spare parts are 
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required to be delivered with the equipment (unless specifically ordered) or 
otherwise maintained by the vendor. 

• The vendor will be responsible for all testing at his facilities to demonstrate 
that the required performance specifications have been met but shall not be 
responsible for installation at NASA facilities. Post delivery responsibilities 
shall include only that technical liaison necessary to verify proper installation 
. procedures and to provide brief familiarization to operating and maintenance 
personnel. 

In general, similar assumptions were made with respect to any specially designed 
equipment. The costs shown in Table 2—3 are intended as costs to buy. This means that 
the vendor is given a set of specifications and any developed circuit diagrams to which 
he designs and fabricates the equipment, and the cost he requires, including a reasonable 
profit, is indicated. 

\ 

Considerations in developing the special equipment costs were: 

© Nonrecurring labor (manufacturing design of the first unit including prototype 
and test). 

® Recurring labor (assembly and unit test for each additional unit). 

© Parts cost for prototype (includes 15 percent for G&x^). 

© Parts costs for each additional unit (includes G&A plus 5 percent for shrinkage). 

\ 

© Analog circuit manufacturing labor overhead, 150 percent. 

© Digital circuit manufacturing labor overhead, 100 percent. 

© Profit on total labor, overhead, G&A and shrinkage, 10 percent. 

Off-the-shelf hardware costs are the manufacturer’s current list prices, less discounts 
for quantity purchases. 

A special breakdown for AGIPA channel hardware costs was made. The first 
channel cost (prototype) is estimated at $159, 9K, and the next channel cost is $30, 9K 
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Table 2-4 shows the total cost as a function of the number of channels and the cost per 
channel. Twenty-four channels are priced in Table 2-2 for Unit 70. Using the. 24 -channel 
cost from Table 2-4 and adding the cost of the NASCOM switch equals the Table 2-2 value 
($869. 5K + $12K = $881. 5K). Table 2-3 shows the Unit 70 costs in terms of special and 
OSH hardware. The prototype cost is included in the cost of Subunit 73. 

2. 4 DHMS SOFTWARE REQUIREMENTS AND COST 

The baseline DHMS equipment configuration contains 40 computers. Software for 
this equipment does not exist. Therefore, a major cost to be expected is that for computer 
programming. 

An estimate of programmer time has been made. The estimate includes program 
design, coding, and test or checkout times. Also a time allotment for a project manager, 
technical writer, and keypunch operator was included. The total labor cost estimated is 
$1.8M (includes overhead and 8 percent fee). 

The planned software implementation schedule is 18 months. An average of about 
35 people are required during the period. 

Three significant assumptions are made in developing the software costs. First, 
it is assumed that a developed and workable AGIPA channel control program will be pro- 
vided in an understandable format for maping into the language of the channel computers. 

A second assumption is that the hardware will work and that it is described in an under- 
standable text. The third major assumption is that only a minimal program documenta- 
tion effort will be required (i. e. , extensive report specifications will not have to be sup- 
plied or met). 

A developed AGIPA control program should be available from vendors currently 
under NASA contract. However, if the AGIPA design requires a software development 
effort, it should be expected to increase the software costs. Furthermore, should debug- 
ging of any hardware be required, the software costs will increase and the implementation 
schedule will lengthen. Documentation of the software should be understandable by a tech- 
nical manager and a usable reference for programmers. Establishment of the documentation 
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Table 2-4. AGIPA Hardware System Costs 
(Includes Total Channel to Control System Interface) 


First AGIPA Channel Subsystem $159,900 (Hardware) 
Next Channel Subsystem $30, 850 


Number of 
Channels 

Total Cost 

Cost/Channel 

1 

$ 159,900 

$159,900 

2 

190,750 

95,375 

3 

221,600 

73, 867 

4 

252,450 

63, 113 

5 

283, 300 

56,660 

6 

314,150 

52,358 

7 

345,000 

49,286 

8 

375, 850 

46,981 

9 

406,700 

45, 189 

10 

437,550 

43,755 

11 

468,400 

42,582 

12 

499, 250 

41,604 

13 

530,010 

40, 777 

14 

560,950 

40,068 

15 

591, 800 

39,453 

16 

622,650 

38,916 

17 

653,500 

38,441 

18 

684,350 

38,019 

19 

715,200 

37,642 

20 

746,050 

37,303 

21 

776,900 

36,995 

22 

807,750 

36,716 
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Table 2-4. AGIPA Hardware System Costs (Continued) 


Number of 
Channels 

Total Cost 

Cost/Channel 

23 

$ 838,600 

$ 36,461 

24 

869,450 

36, 227 

25 

900,300 

36,012 

26 

931, 150 

35, 813 

27 

962,000 

35,630 

28 

992, 850 

35,459 

29 

1,023,700 

35,300 

30 

1, 054, 550 

35, 152 

40 

1,363,050 

34,076 


AGIPA switch to NAS COM adds $12K to total. (24 Channels) 
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format would be made prior to program development. Only a few, simple specifications 
should be required for the software reports. The details of the software requirements 
estimate are provided in Table 2-5. 

2.5 IMPLEMENTATION COSTS 

Hardware and software element costs for the DHMS have been estimated. However, 
for the DHMS to work, these elements must be installed in the physical TDRSS GS. The 
implementation costs are estimated as percentages of the DHMS hardware cost as follows: 

© Installation, Integration and System Test 35 percent 

o System Documentation 25 percent 

© Equipment Spares 10 percent 

$ Systems Engineering 10 percent 

© Program Management 10 percent 

These total to 90 percent of the hardware cost. Thus, DHMS implementation costs are 
estimated to be $2,569. 7K (0. 9 x $2, 855. 2K = $2,569. 7K), which includes the Imple- 
mentor’s overhead and profit. 

Installation costs are assumed to include the costs for cabinets and interunit 
cables that are not otherwise included in the basic hardware prices. Other equipment 
costs are for spares which would be used to maintain the DHMS. The remaining costs 
are for professional labor, with small allotments for travel and living expenses plus 
miscellaneous supplies (i. e. , paper, report binders, etc.). 

2.6 TOTAL DHMS COST 

The total DHMS cost is composed of the hardware, software, and implementation 
costs. These total to $7,224.9K ($2,855.2K + $1,800. OK + $2,569.7K = $7,224. 9K). 
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Table 2-5. TDRS Ground Station 


1. WTHuni'CTlON TO KOFTWAHK KEQVWEMENTS OF THE THUS OIUH.1NH 
STATION , „ „ 

(i or 2) 

Th<- fund inns performed :uul the backup provided by the processors uro explained 
I jo low: 

A. Control System 

1. Command and Conti pi rat ion Processor (PPP-U/ia) 

I lie lunolloiis of the command and confijm ration computer are to input all con- 
fljjnrnl ion control commands, buffer and output all spacecraft commands, 
check verification ol all commands and monitor the '’monitor processor." if 
a failure 111 the monitor system is detected, alert ihe (IS maintenance personnel. 

Monitor Processor (I'DJ’-l 1 /|n> 

As ihe system monitor computer, monitors all computers and if required 
automat (ealty perform ail switchover functions, transfer configuration status 
in new computer and outputs stains to displays for new computer configuration, 

I he monitor computer can lx.’ used to backup Ihe function of the command and 
confl spiral ion computer and also the i-DK/TUUS/H&ii computer system. 

•'*. LdM/T!>KS/IUU Processor fl'DP-l 1 / t!i) 

Ihe liinclion of the I.I)U/'J'l>lts/tH;l< computer system is lo control the assign- 
ment' of each U)tt .UtlPA downlink channel, store nil required I, 111! and TIJllK 
playback daia, com mi the assignment of the TDHS downlink computers, output 
si on si daia npon request lo NAUCOIM, bloc); and formal all US rk datii for trans- 
fer In NASI ON. 

I he 1,1)11 r 'i I'lt-S/USrli system can be used lo backup the command and conflinirn- 
lion computer, but only if the test /backup system ami (he monitor system have 
lulled. 

; i. 'l est S- backup Processor <PI)P-l l/t n) 

The test k backup processor Is used for system testing, software development, 
and as a backup for the command and eonflnu ration system, the LDU/TDRS/ 

Hilt system ami the monitor system in that order. 

H, l.l >H (At I! PA | Computer Systems <:> I -PDP-l 1/03) 

iuK’lt PUP- 1 ! /da computer is used as an interface to each AUJPA channel. Each 
ermipuier performs the followinjt functions. 

1, I' mine synchronization or data and NASCOM blocking 

Control point hi" (ad jus Is phase and attenuator circuits) 

(Vint ml Ain i>A elements 
1. Program PN code generator 

a. Program input switch 

d. Program bit rate 

Onlpul blocked user data to NASCOM 
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Table 2-5. TDRS Ground Station DHMS Software Requirements (Cont’d) 





OF THE 


Table 2-5. TDRS Ground Station DHMS Software Requirements (Cont’d) 


n. NASCOM OAT A LINKS 

Software Roq'd 
for Computer 
Subsystem 

Resident 

(Words) 

Foreground/ 

Background 

(Words) 

Coni mon 
Sto rage 
(Words) 

Disk 

Storage 

(Words) 

Senior 
Analyst 
(Man Months) 

Programmer 

Coder 

(M.'>r Months) 

System 

Test 

(Man Months) 

A. Two !i(i-(<bps High .S|*u‘<! Modems 

Command and 
Configuration 
Computer 

HOOD 



7000 

14 

(1 

(> 

1. Command data messages Tor LDTt, M DU, Shuttle and TDRS 

2. Command verification aeknowlc element back to users 

3. Configuration control commands (Ren l-l inie/Sto red Schedule) 
-1. Operator messages and message acknowledge chocks. 


- 







11 . Composite Status of Ground Station 

Collect the current station status, users being serviced, system status and the 
THUS telemetry data. Package this information into a NASCOM Tormat with 
proper header information ami send to TORS OCC via NASCOM, 

Command and 
Configuration 
Co mputer 

1000 



1000 




C. Three Range nnd Range Rate Data Links 

LDR/T D11S/R&R 
Computer 

2000 



2000 




!. M OR 2,4 kbps, simplex link (10 sum pies /second with each sample having 
240 bits). 1 





IU0U 




2. L!)it 2.1 kbps, simplex link (1 sample/ second for each of 20 users) flviich 
sample having IDO hits). 





1000 




3, M DR 1.2 kbps simplex link (1 sample/second for each of 4 users) (K.ach 
sample having 240 lilts). 

D. The LDR/TRRS/R&R computer, upon command, accepts LOR blocked user data 
tor storage that can bo played back later to CSFC upon command, (Storage 
capaetiy for 20 users at 1 1 kbps eaeh for 2 hours). 

K. TI>US spaeoc valt telemetry (lata link for playback to TDRS OCC in NASCOM 
blocks. 

LDR/TDRS/RWl 

Computer 

r.DIt /TDRS/R&R 

500 

500 


2500 

500 

1 000 
15 DM 
SOM 



. 

I '. TORN spacecraft telemetry data link for real-time traits mission in NASCOM blocks 
to TORS OCC. 

TORS Computer 

2000 



2000 




C, M1)R telemetry data links lor real-time and playback on any one of eight simplex 
links (1 rnl>ps links). 

MDR Computer 

5000 


240(1(1 

Com pi etc 

Disk 

System 




11. LOR real time playback of data from each of 20 users (total of 24 channels being 
scheduled by the LDR/TDRS/R&R computer subsystem In a cyclic manner), 

LDR A Cl PA 

2000 
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Table 2-5. TDRS Ground Station DHMS Software Requirements (Cont'd) 



Software fieq’i) 


Foreground/ 

Common 

Disk 

Senior 

Programmer 

System 

Test 



for Computer 

Resident 

Background 

Storage 

Storage 

Analyst 

Coder 


?; (1 of 5) 

Subsystem 

(Words) 

(Words) 

(Words) 

(Words) 

(Man Months) 

(Man Months) 

(Man Months) 


A. Spacecraft Commanding Subsystem 

Command and 
configuration 
computer 









1. Command Data Buffer. Router and Verification Processor 


2000 


1500 

4000 

10 

4 

2 


2. Command Input Processor 










a. Heal time commands from T.DR, MDR. and TDRS users 


700 



700 

5 

2 

1 


b. Scheduled commands from LDR, MDR, and TDRS users 


rjoo 

4000 


5300 

5 

2 

1 


c. Manually generated commands from keyboard console 

tl. Group command-sets stored in station (200 command groups for each 


r,oo 

2000 


2500 

12 

3 

:i 


user, with each group containing an average of 4 command sets) 
assuming 20 T.DR users. 4 MDR users, and ;i TDRR spacecraft 






12 

3 

0 


■0. Editor Program for Group Command System 



2000 


2000 

I 

1 

2 



4. Editor Program for Configuration Control Schedule 



2000 


2000 

1 

f 4 



B. Configuration Control Subsystem 

■■ 









1. Configuration Control Executive 


200 

1000 


1200 

18 

0 

4 


a. Execute real time or predefined schedule configuration control 
commands. (Update configuration status) 

b. Execute automatic configuration control cltnngos due to system failure 



soo 

2000 

2800 

4 

2 

l 


cheeks 



,0000 


3000 

12 

4 

2 


c. Monitor status of all 240 (approximately) ground station equipments. 










The following status to be kept on each unit. 



500 

1000 

1500 

S 

2 

j 


(1) Whether unit is GO or NO-GO 
: (2) Whether unit is 'leg railed or usable 

(3) Whether unit is presently assigned to a link and which link 

(4| Number of points being monitored for each unit 

(51 Criteria to be used in evaluating whether a unit is failed or usable 










d. Control configuralion status of each RF and matrix switch 


TOO 

1000 


1100 

2 




e. Control configuration status of each equipment link (chain) 


100 

1000 


1100 

12 

4 

2 


(1) Command and command verification links. 

(2) Telemetry links for I.DR, MDR, SIT UTTER, TDRS and O. W. 
(.1) Range and range rate data links 










f. Simulator control chock of each link before to user 


500 

2000 


2500 

8 

2 

4 


g. After any configuration change, automatically update configuration status 


yoo 

1000 


300 

1 

i 

1 
















ig 

*■! 

se 

ig 


W 




to 

i 

w 

to 


Table 2-5. TDRS Ground Station DHMS Software Requirements (Cont'd) 


CONTROL SYSTEM 

Software Rrxj'd 

— 

Forcgrou nd/ 

Common 

Disk 

Senior 



for Computer 

Resident 

background 

Storage 

Storage 

Analyst 



(2 of 5) 

Subsystem 

(Words) 

(Words) 

(Words) 

(Words) 

(Man Months) 



Configuration Control Subsystem (Continued) 

2. Parameter Input Formats Required to Perform Configuration Control 









Changes 


100 

1000 


1100 

12 

0 

3 

3. Event iminter Outputs 


100 

3000 


aooo 

4 

4 

2 

a. Configuration changes 
h. Failure of any piece of equipment 
c. Replacement of any failed equipment 
A. Command verification failures 
c. Messages 
f. Milestone information 









4. Simulator Control 


100 

3000 


4000 

6 

:i 

:> 

Commanding of simulator system for special data patterns so that a 
downlink channel can bo pretested before committing it to use 









5. Display Console Alert Program 


200 

1000 


1200 

2 

i 

t 

a. Indications of nil command verification failures 

b. Uplink or downlink channel failures displays 









(5. Display Console Command input Program 


200 

3000 


3200 

2 

i 

l 

a. Real time group commanding 

b. Recycling of a failed sequence 

c. Processing of control override pushbuttons 

d. Cleaning of CRT page displays 









Monitoring the "Monitor System" 

Command and 

configuration 

computer 

100 

1000 


1100 

4 

1 


Monitor System 









l. Display and Monitor Consoles 


100 

1000 


1100 




The display and monitor console will bo made up of a GO/NOGQ status light 
section, a CRT display section, a command control panel and a keyboard 
input section. Throe identical consoles are being proposed for redundancy 
and (o service a ground controller, system controller, and un operation 
director. The following discussion indicates the proposed functions of each 
section: 








' 
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Table 2-5. TDRS Ground Station DHMS Software Requirements (Cont’d) 


III. CONTROL SYSTEM 

(1) of 5) 

Software Itcti'd 
for Computer 
Subsystem 


Foreground/ 

Background 

{Words) 

Com men 
Storage 
(Words) 

Disk 

Storage 

(Words) 

Senior 
Analyst 
(Man Months) 

Prog r, i m me r 
Osier 

(Man Months | 

System 

Test 

(Man Months) 

I). Monitor System (Continuer!) 









a. GO/NO--TO status section 

Monitor 

1000 



2000 

10 

4 

1 

This panel will display such things as: 

Computer 








(1) Command and command verification status of each command tine 


200 



1000 




(2) Downlink status of each of the 20 LDK users and whether they are 




4 00 

000 




in lock with TDRS No. 1, No, 2. or both 




50 

150 




(.’I) Downlink status of each MDR user on channels 1. 2, 3, or 4 for 


100 







each TDRS 









(4) TDRS telemetry status for all three TDRSs 


100 

3000 

50 

2100 




(5) Configuration of minicomputer command and configuration control 


100 

500 

50 

700 




computer 









(li) Configuration of minicomputer monitor system 


50 

500 

50 

000 




(?) Configuration of minicomputer LDR/TDRS/Uiitt system 


50 

500 

50 

O'OO 




( H) Configuration of minicomputer test and backup system 


50 

500 

GO 

000 




(0) Configuration of minicomputer TDRS system 


50 

500 

50 





(ID) Configuration of minicomputer l.DIt system 


50 

500 

50 

(100 




(ID Configuration of minicomputer MDR system 


50 

500 

50 

(100 




(12) Configuration or minicomputer T4ASCOM data links 


50 

500 

50 

(100 




(13) Configuration oT minicomputer all other uplink anil downlink 


50 

500 


. 000 




sy*! Mms 









(Ml Time display 


100 



100 




h. CUT System 

Monitor 

2000 



2000 

9 

4 

1 

Tin* CUT sysuni Uinu proposed will contain Ihruu coni rollers 

Computer 








and three scririis, one lor each console. A ha rd copy of any 









CRT ((age Can fa- made. Kacti console will have a thumbwheel 









control In allow (hr opt: m Utr n suction of up l<> !12 diffurenL 









CRT pages. The following would be typical tyin.'s of rwge 









'displays; 









(1) Display of command and command verification status showing 


50 

3000 



1 



command failures and noncomparing hits 







i 

1 

(2) l.DIt downlink display page 


50 

3000 


3100 

1 

\ 

£ 


(3) MDR downlink display page 


50 

3000 


3100 

1 

1 

1 

(1) TDRS downlink display page 


GO 



3100 

1 

J 

1 

(5) Range and range rate data display page 


50 

3000 



! 

2 

T 

' ((>) NASCOM data links in operation display page 


50 

3000 


3100 

1 

1 

7 

(7) Manual command am! command group display page 


50 

3000 


3100 

1 

7 

7 

fit) Kcpjipmcnl status display page 


5(1 

30(10 


3100 

1 

ij 

i 

(9) Configuration display page 


DO 

3000 


3100 

1 











Xf-Z 


Table 2-5. TDRS Ground Station DHMS Software Requirements (Cont'd) 


!H. CONTROL SYSTEM 

Softwa re Heq'rl 
for Computer 

Re a Went 

Fore ground/ 
Background 

Gammon 

Storage 

Disk 

Storage 

Sente r 
Analyst 

t’rng ram mor 
Coder 

System 

Tt?st 

(4 of S) 

Subsystem 

(Words; 

(Words) 

(Words) 

(Words) 

(Man Months) 

(Man Months) 

(Man Months) 

l>. Monitor System (Continued) 









(30) Schedule call-up display page 


50 

,1000 


3050 

1 

1 

1 

(31) Event page of configuration changes, equipment failures, equipment 


50 

3000 


30C.Q 




back in operation, messages from central, etc. 






1 

a 

t • 
£ 

(32) Changeable Input pages for predefined status and monitor items 


500 

! OOP 


4500 

1 

\ 

h 

c. Hard Copy Outputs 


500 



GOO 

7 

a 

4 

Hurd copy outputs of the following would ho typical of the type required 
in the TDRS ground station 









(1) Hard copy of anv CRT page 


300 



300 




(2) System configuration status 


100 

3000 


3100 




(2) Diagnostic system printouts 


100 

4000 


4100 




(-1) Schedule information 


100 

4000 


8000 




(5) Group command output* 


100 

3000 


7000 




il. Keyboard Control 


1000 

4000 


8000 

10 

H 

2 

Three kcyl wards will be provided, one at each console, Each keyboard 
would bo used to input configuration changes, manual commands, group 
commands, diagnostic system checks, simulator inputs, etc. 









2. Equipment RUitus 


100 

3000 


31 00 

2 

I 

1 

Pass back to prime system equipment statUR changes, such as equipment 
failures, equipments bnek on line and degraded status of equipments. This 
information would then be used by the prime control computer to update the 
station configuration accordingly. 









2. Monitor Computer Control of Minicomputer Switchover* 


200 

1000 


2100 

0 

,1 

1 

As the system monitor minicomputer, monitor all minicomputers and if 
required automatically perform all switchover functions, transfer 
configuration status to new computer and output status to displays of new 
minicomputer configuration. The monitor computer can be used to back up 
the functions of the command and configuration computer, only if the test 
backup system has failed. 









!•;. Simulator Software System 

Configuration 

100 



4100 

3 

2 

2 

Simulator system will allow for ground loop checks of all downlink type data 
i formats. The simulator system will be eommandahlc via the configuration 

1 control computer and any type of data patterns for link checkouts will be 

commandable. 

Control 





1 




i 

( 

i 
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Table 2-5. TDRS Ground Station DHMS Software Requirements (Cont’d) 


Mi. 

CONTROL SYSTEM 

(5 of 51 

Software Hoq’d 
for Computer 
Subsystem 

Resident 

{Words) 

Foreground/ 

Background 

(Words) 

Corn mon 
Storage 
(Words) 

Disk 

Storage 

(Words) 

Senior 
Analyst 
(Man Months) 

Programmer 

Coder 

(Man Months) 

System 

Test 

(Man Months) 

F. 

Utility Software 

Utility software programs will be required to help in 
of programs to be developed are: 

system checkout. Type 


1G00 

•idotio 


49UOO 

(1 

8 

. 2 


1. Diagnostic Programs for Each System 

2. Raw Printouts of Both Types of Rata Expected 
2. Uplink and Downlink Command Printouts 

4. Etc. 










C. 

Real Time System Programming Support 











Assumption being made that total implementation of system to take IS months. 
The following is the additional support for the operating systems required. 










1. Real Time Executive Development 
(Senior System Analyst) 

2 people for duration 






ftB 




2. Softwaie Maintenance and System Generation 
{Senior Programmer and Programmer Analyst) 

2 people for duration 






IS 


is 


ft. Communication Handlers 

(Hardware/Software Engineer) 

1 person for duration 






1ft 




4. Peripherals 

(Hardware 'Software Engineer) 

1 person for duration 






IS 




5. System Testing 

2 people for duration 






1ft 


jft 

II. 

Document at ion 








. 



1 Technical Writer with So ft ware/ Hard ware Background 
.1 Technical Writer 

2 people for duration 






1ft 


IS 

1. 

Manager 

1 manager for duration 
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Keypunch Operator 

1 person for duration 
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2. 7 COSTING DELTA 


The LDR return link DBMS elements are the AGIPA channels. They are designed 
to operate with eight signal streams from either active TDRS or a test input and with 
four discrete data rates within an overall range of 0. 5 to 10 kbps. A cursory costing 
estimate has been made for a different AGIPA concept. The cost difference (delta 
change) for this revised concept is discussed. 

Modified AGIPA channels are to receive signal streams from 30 sources 
eminating from the active satellites or the test system. Furthermore, they are 
designed to handle data rates within a range of 0. 5 to 32 kbps. 

There are two significant DBMS cost impacts. The first is for each AGIPA 
channel signal processor, and a cost increase of $11. 9K is estimated. Secondly, 
it is felt that the LDR data recording capability must be removed from the control 
system. A separate PDP 11/45 computer system would be used to concentrate the 
AGIPA channel data outputs for the 2 -hour maximum rate recording capability. 

This computer system with AGIPA channel intercomputer communications is 
estimated to cost $66K. 

The LDR disk controller and two drives from the control system (Unibus 
systems 3 and 4) would be used, and one additional $17. 9K drive would be added to 

9 

provide a recording capability of 4. 8 Gb (4, 8x10 bits). Although a 2-hour recording 
at the maximum LDR data rate, 704 kbps [704 kbps = 20 x (32 kbps + 3.2 kbps)] 
including 10 percent overhead on the data for time and status tagging, would require 
5. 1 Gb, the cost for the small capacity above 4. 8 Gb would not be warranted (an 
additional disk drive at $17. 9K). 

The modified AGIPA channel concept is estimated to require a delta hardware 
cost increase of $369. 5K (24 x $11. 9K + $66K + $17. 9K = $369. 5K). The previous 
software cost should not be affected. Considering the implementation cost (90 percent 
of the hardware cost), the total modified AGIPA concept delta cost is estimated at 
$702. IK [(1 + 0. 9) x $369. 5K = $702. IK]. 
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The first modified AGIPA channel is estimated to cost $178,900, and the next 
channel cost is $42,450, The major increase over those costs shown in Table 2-4 
results from the additional 22 variable phase circuits and attenuators used to maximize 
the signal to interference ratio and circuitry associated with these devices. The var- 
iable bit rate handling capability adds only $700 to the channel cost. 

It is assumed that the PDP 11/05 has adequate capacity to process measurement 
data from the 30 input signal streams. The Viter bi decoder in each AGIPA channel 
can handle up to 100-kbps data rates. 

Note that the S-band input signals must be down converted to an IF around 
100 MHz before being processed in the AGIPA circuits. If the signal interference is 
not too great at the S-band frequencies the variable attenuators may not be needed 
for the modified LDR downlink system. In this case, the first modified AGIPA 
channel costs $174,700, and the next channel price is estimated at $38, 250. 

Under the assumption that the variable attenuators are not required, the costing 
delta for the modified AGIPA concept is $268. 7K (24 x $7. 7K + $66K + $17. 9K = 

$268. 7K). Adding the implementation percentage increases the estimated delta cost 
to $510. 5K [(1 + 0.9) x $268. 7K = $510. 5K], 
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SECTION 3 - NAS COM INTERFACE SYSTEM 


3.1 GENERAL 

The NASCOM interface system (Unit 10) is briefly covered in this section. 

There are eight types of links composed of 46 separate channels that are configured 
between the DBMS and Unit 10 (see Figure 2-1 and Table 2-3). 

3.2 RANGE AND RANGE RATE LINKS 

Three separate range and range rate (R&R) channels originate in the DHMS. 
They are assumed to be simplex channels that terminate at the GSFC. 

A high sample rate [10 samples per second (sps)j R&R channel is provided for 
MDR users. Data for one of four possible users are put onto the channel at any given 
time. The particular users’ data are selectable via the control system (Unit 20) as 
directed by the stored schedule or real-time TDRS OCC commands. 

Each sample is assumed to require 240 bits, being similar in format to the 
R&R samples provided by the Manned Space Flight Network's (MSFN's) Tracking Data 
Processor. Therefore, the channel rate is approximately 2. 4 kbps (10 x 240 bits per 
sps - 2.4 kbps). 

The data are formatted into messages in the control system. After a message 
is formed, a "data ready” signal would be enabled for Unit 10. Unit 10 would then 
transfer the messages from the Unit 20 interface at rates greater than 2.4 kbps to a 
maximum of 500 kbps. A NASCOM clock is required to effect the data exchange. 

In general, data transfers from the DHMS are handled similarly. For each 
active channel the DHMS would supply a "line in use" signal to the interface and 
receive a "line active" signal that would indicate the interface was operating properly. 
A polynomial code is assumed to be applied in Unit 10 that would be monitored at the 
GSFC, Excessive NASCOM~detected errors would be used to inform the control 
system of a communication failure. However, provisions for repeat R&R messages 
have not been incorporated into the DHMS, 


3-1 



The second R&R output is a composite channel. It conveys 20 LDR users' R&R 
information, allowing' 120 bits per user. Time and R&R data are encoded at a rate of 
1 sps. Therefore, a second 2.4-kbps (20 x 120 bits per sps = 2.4 kbps) channel is re- 
quired. In this case the control system time division multiplexes (TDMs) the LDR 
users' data into the composite NASCOM messages, where user No. 1 is assigned the 
first 120 message bits, user No. 2 the second 120 bit slot, etc. 

A third R&R channel is supplied for all MDR users. The channel is composed 
of 1 sps for each of four possible simultaneous users, where each sample is assumed 
to be 240 bits. Only 1. 2 kbps (4 x 240 bits per sps = 0, 96 kbps) are necessary that in- 
clude about 200 bits per second for user' data identification. One MDR user’s data are 
duplicated because they can be on the high rate channel (10 sps) and the composite 
channel (1 sps) simultaneously. 

Note that provision has not been assumed for the TDRS’s R&R data. This could 
be done, and the data TDMed with the composite MDR users’ data, bringing the channel 
rate up to 2. 4 kbps. Thus each of the three R&R channels would require the same 
NASCOM communication capacity. 

The sizing (capacity) for the three R&R channels is approximate and is subject to 
change as a detailed TDRSS design evolves. However, the capacity outline is con- 
sidered adequate to handle the expected R&R data loading, 

3. 3 COMPOSITE STATUS LINKS 

One prime and one backup composite status channel originate within the DHMS 
control system. The status messages include bits for 20 LDR and 4 MDR users, and 
the three TDRS’s ground systems. Each channel is redundant, simplex, and assumed 
to be simultaneously transmitted with the other channel on diversely routed paths. 

About 200 bps are available for each of the 24 users. The channel rate is 4.8 kbps 
(24 x 200 bps per user = 4. 8 kbps). The status bits are used to indicate GS equipment PN 
code lock with the user spaceci'aft, ground-link command verification, GSFC-to-GS 
command message verification, message numbers accepted and rejected, etc. 
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One or two messages per second could be communicated, providing 200 or 100 
bits per user, respectively. Demultiplexing of the composite status data at the users’ 
MCCs provides all basic information believed necessary about the TDRSS handling 
of the forward link data. Actual return link spacecraft data are required by the 
MCCs, also, for mission operation. Ground station problems or communication 
outages would be indicated in the status data in the cases where the real-time 
spacecraft data were not being received. 

Therefore, only a minimum of voice communication with the TDRS OCC 
personnel should be required by the MCC operators. Furthermore, the TDRS OCC 
would have the composite user and GS status available as a backup to any particular 
MCC. 

Data transfer from the control system occurs at a rate greater than 4, 8 kbps 
but less than 500 kbps. The NASCOM interface system would operate as described 
for the R&R data channels. 

3.4 LDR PLAYBACK LINK 

The LDR contingent disk recording equipment is currently located in the 
control system. One channel is provided to transfer data from Unit 20 to the 
NASCOM interface system. Only one of the possible 20 users' data would be put 
into the channel at a given time (i.e, , LDR data TDMing is not performed). 

A particular time duration of recorded data for a user is selected by the control 
system, or all recorded data for a LDR user can be played from the disk recordings. 
The particular option is commanded by the TDRS OCC, not by the LDR MCC. 

Because the LDR user data can be played back slower or faster than they were 
recorded, NASCOM is free to select the channel transfer rate up to 500 kbps; 
however, the channel rate (average playback rate) would be established by NASCOM 
and the command system load at the particular time. This means if concurrent 
recording of data is being accomplished, a channel rate up to 200 kbps could be 
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supported for one user. Two users requesting data at the same time would reduce 
the outgoing rate below 100 kbps per user because of the overhead handling involved. 
Additional output requests would reduce the rate more. Also each user's data would 
be in a time contiguous segment requiring NASCOM line switching between segments. 

Higher channel rates, up to about the 500-kbps transfer rate, could be 
supported if LDR data recording were not in progress. As before, however, the 
channel rate per user would be reduced as the number of users’ playback data 
segments, per unit time, increases. 

3.5 COMMAND AND COMMAND VERIFICATION LINKS 

The command links are assumed to be dual and diversely routed from GSFC to 
the GS and to operate at a 56 -kbps channel rate. They go between the NASCOM 
UNIVAC 494 message switch and the control system. 

All user, TDRS, and TDRS-GS forward data come into the DHMS through the 
command NASCOM interface. Any message with a NASCOM-deteeted error is 
dropped. This means that the control system will not forward a command or change 
the GS configuration as a result of the particular message contents. 

A "message in error" indication is formatted, however, and returned to the 
sender via the status links. It contains the received message identification number 
(if decipherable) and other information so that the user can know to retransmit the 
message. 

Messages are not duplicated on the two incoming command channels, and each 
message is handled appropriately by the control system. Accepted messages 
are acknowledged by Unit 20 on the outgoing status channels from the GS to the senders. 
However, the acknowledgment of proper receipt or "message in error" is duplicated 
on both of the outgoing channels. This means that one incoming and one GS-to- 
GSFC channel could be down without affecting GS operations, assuming that all in- 
coming data messages were received over the viable channel. 
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Modifications to the control system operation are expected as more becomes 
known about Unit 10. Unless significant changes are required, the Unit 20 and soft- 
ware costs would not be expected to change significantly. 

3.6 LDR REAL-TIME LINKS 

There are 20 separate and distinct LDR real-time user channels input from 
Unit 70 into the NASCOM interface sj^stem, A minimum transfer rate of 0.5 kbps to 
a maximum 10 kbps plus overhead is required for each channel, (Ten percent over- 
head has been assumed for study purposes. ) 

Similar to the previous transfer rate discussion, NASCOM must supply the 
data transfer clock to the DHMS. The minimum transfer rate is greater than the 
LDR user plus overhead data rate, and it is limited to less than 500 kbps. 

Scheduled use of the channels is assumed, and handover from one TDRS to the 
other for support of a given user does not change the user channel at Unit 10. 

Although a different AGIPA LDR channel is in use after handover, the control sys- 
tem maintains the user’s data on the scheduled NASCOM channel by control of the 
LDR user NASCOM switch in. Unit 70. 

3.7 TDRS REAL-TIME LINKS 

One discrete channel for each TDRS housekeeping data is supplied by the 
DHMS to Unit 10. It is backed up. Therefore, six channels are provided, three of 
which duplicate the remaining channels. 

A message formatted in Unit 80 can be transferred to the interface at a maxi- 
mum rate of 500 kbps. The channel rate is undefined, but it is expected to be less 
than 10 kbps. The orderwire event bits are included in the TDRS data messages from 
the on-station satellites. 
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3.8 MDR USER LINKS 


There are eight MDR user data channels that input to the NASCOM interface 
system. Each is independent of the rest, except they all go through the MDR user 
NASCOM switch located in Unit 90. 

Real-time and recorded MDR users’ data are communicated in the channels, 
and transfer rates greater than the user real-time data rates plus overhead can be 
handled up to a rate of 1 Mbps. All channels are scheduled by the control system 
activity. The channels are simplex. 

Recorded data can be selected bjr time interval for replay via Unit 20 control 
similar to the playback considerations for the LDR users’ recorded data. Note 
that data recordings are only to back up NASCOM link outages and to solve the 
NASCOM overflow problem when several high-rate telemetry dumps are received 
from the MDR users’ spacecraft. A store-and-forward GS concept is not implemented, 
and most users' data would be formatted in real-time for transfer to the users* 

Line control is similar for all digital channels. Specific details can be 
worked out during a detailed design of the DHMS. In general, significant cost changes 
are not expected. 

3.9 SHUTTLE VOICE LINKS 

Two incoming shuttle voice links, 4-kHz nominal bandwidth, are assumed for 
Unit 10, each backed up and connected to Subunit 33, the shuttle forward command 
and verification buffers. Duplex channels are assumed, on which return voice would 
be input to Unit 10 from the MDR/shuttle downlink system (Unit 90). 

Forward voices No, 1 and No, 2 are duplicated to Unit 30, and return voices 
No. 1 and No. 2 are duplicated from Unit 90. Thus, specific provision for a verifi- 
cation of the forward voice back to the speaker has not been assumed in Unit 10. The 
forward voice could be verified by GS personnel, however, if it were played to them. 
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Forward line control detects if voice is present on channels No. 1 and No. 2 to 
Subunit 33. If so, A or B Subunit 33 is used. If not, the subunit to which voice channels 
are being received is used in the forward link. 

Return link voice is duplicated from Subunit 92A or B to Unit 10. Therefore, 
NASCOM is free to select either two of the-No. 1 or No. 2 return voice channels for 
relay to the shuttle MCC. 

3.10 UNIT 10 SUMMARY 

The assumptions made in designing the NASCOM interface system for each 
type of forward or return link were stated. It is expected that specific DHMS and 
interface designs will be required that will change some of the described concepts. 
However, the cost impact on the DHMS should not be significant. A specific cost 
for Unit 10 is not provided because the DHMS-to-Unit 10 costs are included in the 
particular DHMS interfacing units. 
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SECTION 4 - CONTROL SYSTEM 


4.1 GENERAL 

This section summarizes the work that has been done in designing the DHMS so that 
it operates as automatically as possible, with little or no intervention by maintenance 
personnel. The use of technicians/operators is limited to maintaining equipment that has 
failed and contingent monitoring of the TDRS and station configuration status, or activating 
and operating the forward link stored user command subsystem. 

The GS is segmented into units, with each unit performing specific functions. The 
GS control system is Unit 20. It is divided into four major subsystems, with each sub- 
system made up of a PDP 11/45 computer and a set of peripherals. The four subsystems 
are: 

e Command and configuration control subsystem 
© Monitor subsystem 
© LDR/TDRS/R&R subsystem 
« Test/Backup subsystem. 

The following paragraphs describe the DHMS control system. 

4.2 CONTROL CONFIGURATION 

The control computers are configured into a multiprocessor type of arrangement 
where any two of the four computers can perform all required real-time operations. 

Also, in a degraded mode one computer can perform all command and command verifica- 
tion functions, as well as configuration control of the MDR and LDR (AGIPA) channel 
assignments. There are four sets of peripherals with each set having one complete back- 
up. Figure 4-1 shows a layout of the control configuration and how each peripheral set 
is switched. 
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Figure 4-1. Control System 
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To make the discussion that follows simpler, each subsystem will be referenced 
as: 

Cl Command and Configuration Processor 
C2 Monitor Processor 
C3 LDR/TDRS/R&R Processor 
C4 Test and Backup Processor 
PI Peripheral Unibus System 1 
P2 Peripheral Unibus System 2 
P3 LDR Peripheral Unibus System 3 
P4 LDR Peripheral Unibus System 4 
P5 Communication Peripheral Unibus System 5 
P6 Communication Peripheral Unibus System 6 
P7 Monitor Peripheral Unibus System 7 
P8 Monitor Peripheral Unibus System 8. 

Each processor has a total of 28K 16-bit words of core memory, a real-time clock, 
a communications arithmetic unit for rapid calculation of longitudinal redundancy checks, 
a DEC writer and a bootstrap loader. Each of the four processors has general-purpose 
intercomputer communication channels between each other. These interfaces permit 
bidirectional 16 -bit parallel transfers of data from computer to computer. 

4.3 COMPUTER PERIPHERAL INTERFACES 

The peripheral Unibus systems shown in Figure 4-1 are controlled by the processors 
under the following formulas. The Cl subsystem is normally configured to operate with 
peripheral systems PI and P5. In case of a peripheral failure, P2 is used to back up PI 
and P6 is used to back up P5. 

The C2 subsystem is configured in normal operations with peripheral system P7. 

In case of a P7 failure, P8 can be switched in. In tills modified configuration only one 
console and CRT keyboard unit would be available to support the GS„ 
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If C2 is used to back up Cl {only if C4 is not available), peripheral systems P2 and 
P5 would be connected to C2. When C2 is used to back up C3 (only if C4 is not available 
and Cl is working), P3 is connected to C2. 

The C3 subsystem is configured in normal operation with peripheral P3. If a periph- 
eral failure occurs on P3, it is backed up with P4. Peripheral systems PI, P5 and P3 
would be connected to C3 when C3 is used to back up Cl (this would be allowed only if pro- 
cessors C2 and C4 were not available). In this configuration all of the functions performed 
by the command and configuration processor would be continued, and the control of each 
LDR channel would still be provided. 

The C4 processor has the capability of being connected in normal operation to periph- 
eral systems P2, P4, P6, and P8, and in a backup mode to peripheral PI. When C4 is 
used to back up Cl, peripheral systems P2 and P6 would be connected to C4. If C4 .is 
used to back up C3, peripheral P4 would be connected. And when C4 is used to back up 
C2, peripheral P8 is connected to C4. 

Table 4-1 summarizes the control system normal and backup processor switching 
capabilities and which peripheral systems are available to the processors. The required 
peripheral Unibus systems for each processor are also shown. 


Table 4-1. Computer Peripheral Requirements 
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4. 4 PROCESSOR BACKUP CAPABILITIES 


In the preceding discussion it was shown how each peripheral Unibus system would 
be switched to another computer in case of a peripheral failure. The following paragraphs 
describe how each computer is backed up in case of computer failure. 

The Cl processor is backed up threefold because its functions could be performed 
by C4, C2, or C3, in that order. If Cl failed, then C4 would be switched in after the test 
system operator was notified and bumped. BUMS capability would not be lost in this situa- 
tion. If C4 was also down, C2 would be reconfigured to take over the Cl functions. Now 
the system monitor functions would be lost, together with the CRT and display console 
operations. The station would still perform all other required functions. 

If C2 was also down, C3 would be reconfigured to take over the Cl functions and an 
additional degradation would occur because all the functions normally performed by the 
C3 system would be terminated, except for the functions of controlling the AGIPA com- 
puter channels. 

The C2 processor is backed up by the C4 subsystem. If C4 is not available, the 
system monitor functions would be aborted except for the CRT keyboard function, which 
would be performed by the C3 subsystem. 

The C3 subsystem is backed up twofold because its functions could be performed by 
C4 or C2, in that order. No DHMS capability would be lost if the C4 subsystem were used. 

If the C4 subsystem was also down, C2 would be reconfigured to take over the func- 
tions of C3; in this situation, the system monitor functions would be aborted. The CRT 
system normally operated by the monitor processor would be operated by C2. 

4.5 COMMAND AND CONFIGURATION PROCESSOR FUNCTIONS 

The main functions performed by the command and configuration control pro- 
cessor (Cl) are to input all command and configuration messages, buffer all commands 
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for output, output all commands sequentially as they are received, make a command 
verification on each command output, and monitor the monitor’s computer system. In 
a degraded mode Cl takes over the function of controlling the AGIPA channels. 

A software flowchart, Figure 4-2, shows the main functions that would be program- 
med into the command and configuration control subsystem. 

4.6 MONITOR PROCESSOR FUNCTIONS 

The monitor subsystem (C2) is designed to allow the monitoring of all computer sys- 
tems. If a failure in any system is detected, the monitor processor automatically per- 
forms the required switchovers, transfers configuration status to a new computer, out- 
puts the status to operator consoles, and alerts the maintainence personnel of the problem. 

The monitor computer drives the console CRT system with up to 32 different page 
displays that can provide a hardcopy output of any page. Certain portions of the GO/NO- 
GO status panel would be driven by the monitor processor. 

All the ground station equipment monitoring points are processed by the monitor sys- 
tem through peripheral systems P7 or P8. Up to 256 analog and 256 digital points can be 
addressed and monitored. Each digital input can accept 8 bilevel values. 

This system can be used to back up the command and configuration computer or the 
LDR/TDRS/R&R processor. The software flowchart, Figure 4-3, shows the main 
functions that would be programmed into the monitor software system. 

4.7 LDR/TDRS/R&R PROCESSOR FUNCTIONS 

The LDR/TDRS/R&R processor (C3) is configured to support the requirements of 
the LDR, TDRS and range and range rate subsystems. It can also back up the command 
and configuration computer, but only if C4 and C2 are not available. When used as a 


Two priorities for LDR user commands are allowed. An A priority command would 
be put at the head of the LDR command queue, and thus put on the forward link at the 
earliest opportunity. All B priority commands are handled in a first in first out (FIFO) 
queue. 
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Figure 4-2. Command and Configuration Control Computer Software System 
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backup to the command and configuration computer the task of LDR channel assignment is 
transferred to the command and configuration subsystem. 

The main C3 functions are to control the assignment of each LDR downlink channel, 
provide for storage of up to 2 hours of LDR and possibly TDRS data for later playback, 
and control the assignment of the backup TDRS and orderwire downlink system, Unit 80, 
AU R&R data are processed through this subsystem and output to NASCOM on three 
simplex channels as described in Section 3. 

Figure 4-4 shows the LDR/TDRS/R&R computer software system. Figure 4-5 
details the logic used in initial acquisition of data for the LDR channels and how these 
channels are switched. Table 4-2 indicates the type of data that would be saved to accom- 
plish the LDR channel assignments. 

4. 8 TEST AND BACKUP PROCESSOR FUNCTIONS 

The test and backup subsystem (C4) is used as a software development and 
backup subsystem, Asa backup subsystem it can take over the functions of the com- 
mand and configuration subsystem, the LDR/TDRS/R&R subsystem, and the monitor 
subsystem. 

All software development and the subsystem checkouts can be handled with the test 
and backup processor. System software generations, updates, assembles, edits, and 
offline processing are performed, as well as special hardware/software diagnostic rou- 
tines. Because an additional 16K words of core memory are provided for C4 (44K total 
compared to 28Kfor Cl, C2, and C3), the main operating system can be loaded and 
special diagnostic software can concurrently reside in core. 

4.9 SYSTEM SUMMARY 

The DHMS control system provides the capability to automate the GS, Futher- 
more, the computer-controlled actions can be directed from the remotely located 
TDRS OCC. 
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Figure 4-4. LDR/TDRS/R&R Computer Software System 
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Figure 4-5. LDR (AGIPA) Initial Assignment Processor 
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Table 4-2. LDR AGIPA Predict Table 




















Four PDP 11/45 processor systems control, monitor, and perform centralized 
GS operations* There are several stages of equipment redundancy that provide for a 
high station operation availability 0 Redundant peripheral Unibus systems connect the 
processor control to the other DHMS units* 

Software and equipment maintenance can be performed with the actual GS equipment 
not in active use. Therefore, a duplicate software development facility is not needed, and 
normal preventative equipment maintenance can be effected without degrading the GS 
operations. 
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SECTION 5 - COMMAND OUTPUT AND VERIFICATION SYSTEM 


5.1 GENERAL 

The command output and verification system, Unit 30, provides the forward link 
interface with the control system and the uplink modulators, and a command data veri- 
fication path (ground loop) back to Unit 20, A special subunit is included to handle the 
shuttle voice data from the MCC. Unit 30 is described in this section, 

5.2 COMMAND AND VERIFICATION CHANNEL OPERATION 

The uplink (forward link) is used to send commands to the user spacecraft and the 
TDRSs. Four basic channel types are defined: LDR, MDR, Shuttle, and TDRS, To 
monitor their operation, a command verification link (CVL) is included for each of the 
uplink channels. Figure 5-1 is a block diagram of Unit 30 that shows the system inter- 
faces with Unit 20, and Units 40 and 50 (the command uplink and command verification 
downlink systems, respectively). 

A special Unibus. interface card is used to connect Unit 30 to the control system. 
This is a simple 16-bit-wide bidii’eciional data interface. It also buses seven address 
bits from the control system. Two cards are used for redundancy, each connecting to 
unibus system 5 or 6 (P5 or P6). The cards are cross strapped with timeout circuitry 
so that only one of the two cards may be active (receive data from or send data to the 
control system) within a selected time interval. 

Each of the unibus interface cards connects to a cabinet interface card. The 
cabinet card buffers the address and data bits for the 16-channel modules (subunits 31 
through 34 plus the switch modules) shown in Figure 5-1. It is also used to generate 
"interrupts" for the interrupt status interface attached to P5 and P6. The output of 
the cabinet card is a 16-bit bidirectional data bus, seven unidirectional address bits, 
a read/write control line, and a strobe pulse. These 25 lines are common to the 14 
command output and verification channels and the two switch modules. 
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A cabinet interface card connects to a channel unit interface. Each channel is 
equipped with two interfaces that allow independent bus control of the channels by 
Unibus system 5 or 6. Address decoding, acknowledgment, and data gating are per- 
formed independently for the two buses, preventing a single failure from immobilizing 
both buses. 

Bidirectional data lines for each channel unit interface connect to the common 
data bus by receive and transmit gates. The outputs of the corresponding receive gates 
on the two channel cards are wire H ORed. " Any failure on these lines is a channel module 
failure that is detected and results in the control system switching' in the spare module. 
Each of the four uplink channel types has a spare channel module. There are a total of 
three LDR, five MBR, four TDRS, and two shuttle modules. 

Two additional modules shown in Figure 5-1 are controls for switching the digital 
signals from the channel subunits to the modulator inputs. The two switches have the 
same dual interface as the command modules, each controlling forward link inputs to 
one of the redundant sets of modulator groups. The CVL demodulator outputs are the 
inputs to the CVL portion of the channel modules via the CVL switch. The CVL outputs 
are also controlled by the two switch modules. 

Any channel module can interrupt the control system for service. This is per- 
formed by a standard DEC interface card with 32 data inputs and two interrupt inputs. 

Each of the 16 channel subunits is allotted two of the 32 bits that are interpreted as 
shown in Table 5-1. 


Table 5-1 . Interrupt Bit Interpretation 


INTERRUPT 

BITS 

CONTROL SYSTEM ACTION 

A 

B 

0 

0 

Interrupt not generated 

0 

1 

Unload (read into Unit 20) the CVL buffer contents 

m 

0 

Load (read from Unit 20) the command data buffer 

B 

1 

Read (into Unit 20) the Command/CVL module status 
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When the interrupt bits are asserted (as shown in Table 5-1), an interrupt is 
generated by the cabinet interface card for a standard DEC input card. Under normal 
operating conditions a channel module needs service only when it requires data from 
or has data for the computer. Any abnormal condition would call for reading of the 
module status to determine the problem. The four states of the interrupt bits are; 
no action, read data (CVL function), write data (uplink function) and read status 
(trouble). When the computer is interrupted it is programmed to read the 16 bits 
associated with the asserted one of two interrupts (for eight modules) and to perform the 
necessary input or output operations for one or more of the eight modules. When the 
required function has been completed an interrupt reset, issued by the control computer, 
clears the source of the interrupt. 

The path of the interrupt reset is the bidirectional (common) data bus. Because 
only 16 channels exist and seven address bits are available, each channel unit is 
assigned eight addresses. The four most significant bits are the actual channel address, 
and the three least significant bits are "function codes.” It is one of these eight func- 
tion codes in conjunction with the data lines that reset the various interrupt sources. 
Additional function codes are used to read data and status and to write data and control 
the subunits. 

5. 3 COMMAND BUFFER OPERATION 

Forward link command data are written into a buffer in the MDR, LDR, Shuttle, 
or TDRS channel units by the control system. This buffer is a first in, first out (FIFO) 
device capable of storing 32 16-bit words. Data entry and data readout for the FIFO 
buffer are asynchronous, with entrjr via Unit 20 and readout by the uplink data clock, 

A "load command buffer" interrupt is generated by the channel unit when the buffer 
drops below one-fourth full. The control system reads the interrupt bits for the 
channel and, if any command data still reside in the computer, outputs three-fourths 
(24 words) of the command buffer’s capacity. With an uplink data rate of 1 kbps, these 
interrupts occur approx! m ate ly once every 380 milliseconds. The one-fourth full 
signal is present as a status bit for buffer monitoring, and a buffer reset is executed 
via the control system as previously described. 



5c 4 COMMAND VERIFICATION BUFFER OPERATION 

Looped back command data from the uplink path are compared in the control 
' system with the data sent to the command buffer. The ground loop or command verifi- 
cation data are read from the CVL buffer in each channel module. This buffer is also 
a 32-word by 16 bit-per-word FIFO buffer. Asynchronous data enter the buffer at 
the forward link rate, and the data are read into the control system as a result of a 
channel module interrupt. 

The CVL buffer readout is enabled after initiating an uplink command by sending 16 
logic Zeros * - and then the command data to the command buffer. The enable is a func- 
tion code command issued by Unit 20 on the common data bus. The CVL buffer is 
loaded starting with the first logic One CVL data bit received after the enable. This 
procedure ensures bit alignment within a word in the CVL with the uplink command 
data. 

An interrupt is generated for the control system when the CVL buffer is three- 
fourths full. The interrupt bits are read and interpreted, initiating a computer read 
of 24 words (three-fourths of the buffer capacity) from the CVL buffer. The interrupt 
would occur approximately every 380 milliseconds for the 1-kbps command rate. 

Normally the interrupts generated by the command and CVL buffers would not 
overlap in time. However, if the condition should occur the command buffer interrupt 
state has priority over the CVL buffer state. Command data would be provided to the 
forward link buffers, and then the control system would read the CVL buffer contents 
for computer verification. 

5.5 STATUS OPERATIONS 

Each of the channel subunits has up to 16 status bits that can be read by the 
control system. Some of the status bits cause an interrupt to be generated when they 
are asserted. Examples of these are buffer overflow for either of the two buffers, loss 
of synchronization in the CVL detector, and loss of PN code generator activity. These 

*"Only one Zero is required but 16 are used to preserve a word format for the command 
data that always start with a logic One bit. 
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interrupts remain set until reset by the control system. The function of most of the 
status bits is to indicate a channel equipment malfunction. An interrupt generated by 
a status bit has hardware priority over both the command buffer and CVL buffer 
interrupts. 

5. 6 LDR CHANNEL MODULE OPERATION 

An LDR channel module (Unit 31) is composed of two channel unit interfaces and 
buffers as previously described plus equipment peculiar to the LDR user forward 
channel. The special equipment for the uplink is an 11-stage PN Gold code sequence 
generator, timing logic for generating the uplink (command) clock, and control for 
modulo two adding the data to the PN sequence. A second PN code generator, a ehip^ 
timing recovery circuit, automatic PN generator phasing, and a data detector are 
required in the LDR-CVL. 

Input timing for an LDR channel is a nominal 5-MHz signal which can be counted 

down by 30 to give a 167-kHz PN code clock. This clock drives two 11-stage PN code 

\ 

generators that are modulo two added to form a Gold sequence. One of the two generators 
has 11 presettable starting states that are used to generate a sequence of 11 by 2047 bits 
before repeating. By counting the PN code clock down by 253 and initializing the count 
with the start of the 11 sequences, a 660-Hz data clock can be generated whose transi- 
tions are coincident with the PN sequence synchronization pulse. Variations in the data 
rate can be accomplished by changing the PN rate or the number of sequences before 
repeating the code. The PN code synchronization pulse is buffered for transmission to 
the LDR downlink ranging system in Unit 70. 

The data clock generated from the PN code clock is used to serially read data from 
the command buffer. These data are modulo two added to the PN sequence, and the re- 
sultant bit stream is sent to the modulator switches. The bit stream is also applied to a 
single pole double throw (SPOT) loop-back switch. This switch is under computer 
control and selects either the CVL demodulator switch output or the uplink bit stream as 
the input to the CVL portion of the channel module. The latter connection serves as a 
test input to the channel module. 

^Chips are used to distinguish code symbols or bits from data symbols. -The chip rate 
is several times the data rate. 
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The CVL portion of the LDR channel starts at the loop-back switch. This switch 
output is applied to a chip timing recovery circuit that derives the PN code clock from 
the incoming bit stream. This clock is used to drive a PN code generator identical to 
that in the uplink section. It is also counted down to generate the data clock. 

To demodulate the command data the PN sequence must be removed from the 
received bit stream. This is accomplished by modulo two adding the PN sequence 
generated in the CVL circuits to the stream. If the generated PN sequence is not in 
phase with the received sequence, the data cannot be detected. An automatic PN 
sequence phasing circuit performs this operation by detecting the number of PN code 
bit transitions occurring in the modulo two sum of the PN code generator and the received 
data. If these transitions exceed a setable threshold during a data symbol interval, then 
the sequence is assumed not to be in phase. The PN code generator is delayed one clock 
interval, and the threshold procedure repeated. When the threshold is no longer exceeded, 
PN code clock synchronization has been achieved. 

Search for correct phasing is aided by using the PN code synchronization signal from 
the forward link generator to initiate the CVL PN code generator. Thus, the search is 
limited to 16 PN code chip intervals. This corresponds to a maximum of about 100 micro- 
seconds of timing uncertainty between the generation of the uplink data and its reception 
at the CVL loop back switch. If for some reason synchronization does not occur after the 
100-microsecond period, the search is restarted at the next uplink PN code synchronization 
signal. Synchronization would normally be acquired within 16 data symbol intervals, or 
less than 25 milliseconds. 

Data detection is accomplished in the same threshold circuit used for the acquisition 
of PN code synchronization. This circuit is an up/down counter that increments one 
count for each PN chip interval. An upcount occurs when the modulo two sum of the PN 
sequence and received bit stream is a logic Zero, and a decrease occurs when a logic 
One is detected. A symbol logic One is detected if, at the end of the data symbol period, 
the counter indicates a negative count whose magnitude is greater than three-fourth of 
the number of chip intervals in a data symbol period (253 for the numbers assumed for 
this design). Similarly, for a positive count greater than three-fourths of the chip 



count a symbol logic Zero is detected. Any count less than the three-fourths limit is 
assumed to indicate that the CVL-PN code generator is out of synchronization with the 
received sequence, as previously described. If this out of synchronization condition 
occurs for two data symbol intervals in a row, then a new PN code search is started, 
and a status interrupt is generated for the control system. 

All the components required for an LDR channel module would be contained in a 
rack mountable enclosure that could be removed without affecting any other channels. 
Indicators on the front panel would indicate online, spare, or faulty module operation. 

5. 7 MDR CHANNEL MODULE OPERATION 

The MDR channel command module (Unit 32) is similar to the LDR module with two 

major differences: the presence of an additional PN code generator, and a 5-MHz clock 

rate for a first PN code generator. The first PN code generator is used for energy 

spreading and it has two modes of operation; a long-code mode and a short-code mode. 

Short code is used for acquiring a user, and the long code for forward link symbol energy 

spreading during data transmission. The former is a single Gold code sequence of length 
14 

2 -1, and the latter is 40 sequences of the same length. By counting down the PN chip 

clock by 5461 and synchronizing it with the long code synchronization pulse, a 915 bps 
data clock with transitions at the long code PN synchronization pulse is obtained. - — 

The second PN code generator (slow-code generator) is used for ranging. It is 
clocked at a 500-kHz chip rate. This signal is derived by counting down the 5-MHz clock. 
Both the long code and the slow code are initiated simultaneously at a short code synch- 
ronization pulse upon command from the control system, 

5. 8 TDRS CHANNEL MODULE OPERATION 

The TDRS channel subunit (Unit 34) consists of the two-channel unit interfaces 
and buffers as previously described plus some minor additional equipment. For the 
uplink, the additional equipment is a data clock generator. This is counted down from 
a 5-MHz reference. The CVL requires a symbol timing recovery circuit. As in the pre- 
vious channel modules the output stream from the demodulator switch is mid-bit sampled 
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to detect the incoming data symbols. Unlike the previous channels, however, a PN code 
modulating sequence is not used. Therefore, the TDRS command data are transmitted 
without the energy spreading operation, and the ground loop CVL data are directly 
detected for verification in the control system. 

5.9 SHUTTLE CHANNEL MODULE OPERATION 

The shuttle channel module (Unit 33) has the same interface and buffers as the other 
channel subunits. Command data are loaded into the buffer by the control system. The 
data are then encoded twice: first by a (15, 9) Reed Solomon code, with the result further 
encoded with an (8, 4) biorthogonal code. The command data are then time division 
multiplexed with two delta -modulated voice signals. 

The combined data and voice digital signals require framing information to separate 
them at the receive end (shuttle spacecraft). This is currently done by inserting one 
framing bit with each group of 9 multiplexed voice and command bits. One -hundred- 
twenty framing bits are used to complete the forward link frame synchronization pattern. 
Therefore a frame is composed of 1200 bits: 480 delta voice No. 1 bits, 480 delta voice 
No. 2 bits, 120 command bits, and 120 framing bits. Figure 5-2 shows a representation 
of one multiplexed frame. The frame pattern is repeated at a rate of 50 per second, and 
the multiplexed data rate is 60 kbps. 


START OF FRAME 


F » A \ A 1 A 2 A 2 ^ A 1 A 1 A 2 A 2 F 2 A 1 


LAST BIT IN FRAME 


•••■ F |20 A 1 A 1 A 2 A 2 CA l A , A 2 A 2 


k 

c 


- FRAMING BIT 

- DELTA VOICE BIT FOR VOICE NO. 1 OR NO. 2 

- COMMAND BIT 


Figure 5-2. Shuttle Forward Link Multiplexed Frame Format 
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After multiplexing, the uplink data are convoluiionaUy encoded with a rate 1/2 
code. This enables a forward error correction capability for the spacecraft decoding 
circuitry. The 60-kbps stream is increased to 120 kbps in this encoding process. 

A PN code is then applied for spectrum spreading. It is called the long code and 
multiplies the 120-kbps rate by about 42 chips per bit, producing the uplink transmitted 
bit rate of 5 Mbps. 

Although the framing information can be the insertion of separate bits in addition 
to the command and voice bits, the framing information could be the starting phase, (all 
Ones sequence) of the PN code. Use of the PN code sequence for demultiplexer syn- 
chronization eliminates the need for framing bits in the output (forward) data rate, but 
it could increase the complexity of the spacecraft equipment. An ideal framing solution 
would allow a PN code sequence (possibly the long code) to have a bit length of an inte- 
gral number (F) of frames. A frame is defined as the number of data symbols between 
repeating code structures. For the case of the 6-kbps encoded data (with the codes 
given), two 24-kbps delta-modulated voice signals, and a rate 1/2 convolutional encoding 
of the combination of these, the frame is 2160 bits long. A second necessary condition 
for this ideal solution is that the PN code sequence chip rate is an integer N 
times the required transmission symbol rate, and that this value N is a factor of F. 

This synchronization should be considered in further system designs. 

The command verification portion of the shuttle module is the inverse of the up- 
link portion. The input signal from the demodulator switches is used to recover PN 
clock timing and to detect the chip stream. Automatic search was described in the 
MDR channel section. There is a slight difference for the shuttle module in that an 
approximately 120-kbps data signal must be detected as well as a 120-kHz clock when 
framing is not tied to the PN sequence. These data and clock are input to a Viterbi de- 
coder which decodes and returns the 60-kbps data stream to a time division demulti- 
plexer. The encoded command data are removed and applied first to the (8,4) decoder. 
The output of this decoder is then applied to the (15, 9) decoder. If the (15, 9) decoder 
detects an error a status indicator is set, and a computer interrupt is generated. 
Command data from the final decoder are input to the CVL buffer. 



Ground ioop digital voice data are not input to the control system,, They are 
input to a delta-voice demodulator that could be connected to a voice transducer (loud- 
speaker) at the GS. Alternately, the voice channels could be returned via Unit 10 to 
the original speaker for quality verification, 

5. 10 COMMAND AND VERIFICATION SYSTEM SUMMARY 

More than a preliminary Unit 30 design was required to develop its costs. The 
command output and verification system performs the significant functions of accepting 
the forward link command data from the control system and formatting them for the GS 
modulation equipment. Also, the ground loop uplink data are returned to the control 
system for verification through Unit 30. 

All equipments have an on-line backup. Therefore single points of failure do not 
exist. This backup capability extends to the special shuttle data handling subunits also. 
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SECTION 6 - UNITS 4-0, 50, AND 60 


6.1 GENERAL 

Units 40, 50, and 60 contain the RF/IF and antenna systems for the two active 
(on-station) satellites and the backup TDR5, A microwave link would be used to 
connect the remotely located antenna systems to the majority of the GS equipment. 

No equipment within these three units is considered to be part of the DHMS. However, 
digital monitor and control and analog monitor circuits are priced in the DHMS for 
control and monitoring activities of the units. 

The command uplink system, Unit 40, connects all of the forward link data from 
the command and verification system to the antenna systems for relay to or through 
the TDRSs. Unit 50, the command verification system, provides channels for return- 
ing a portion of the radiated signals to the verification system for a ground loop com- 
mand check. All user and TDRS signals are connected from the antenna diplexers by 
the downlink system (Unit 60) to the return data handling equipment. The following 
paragraphs describe briefly the three units. 

6.2 COMMAND UPLINK SYSTEM 

Unit 40 equipment provides two modulator banks that are duplicated (redundant) 
for each active satellite. Each modulator bank has two MDR, one LDR, and one TDRS 
modulators (four units). The MDR units are used for the shuttle uplink communication. 
Because the banks are redundant and there are two on-station satellites, a total of 16 
modulator units are required (see Figure 2-1). Redundant modulators are also assumed 
(two units) for the standby satellite commands. 

The active satellite command modulators connect to individual mixers that pro- 
vide tunability for the MDR-modulated signals. The mixer outputs are concentrated in 
two signal combiners that are backed up for a total of four combiner units. These units 
interface to a microwave link that provides a signal channel to the remotely located 
antenna systems (assumed to be about 6 miles away). The backup satellite modulator 
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signals could be connected by cable directly to VHF transmitters located at the TDRS 
No. 3 antenna site, or they could be connected by a microwave radio relay. 

For the active satellite paths, the microwave signals are received and up- 
converted (four units, two prime and two backup) for the Ku band transmitters. Re- 
dundant transmitters connect to the diplexers (redundant units for each antenna) 
interfacing with the antennas. Similar operations are assumed for the VHF system as 
shown in Figure 2-1. 

. Some control and monitoring points are assumed within Unit 40 as shown in 
Table 2-3. However, a specific equipment configuration is required before all points 
can be defined accurately. No costs for the command uplink system are contained 
within the DHMS costs, 

6. 3 COMMAND VERIFICATION DOWNLINK SYSTEM 

Equipment within Unit 50 is not assumed redundant. Therefore, any unit failure 

\ 

can cause the loss of one or more ground loop command signals that are input to Unit 
30. 

Radio frequency tapoffs are assumed in Unit 40 that supply a low-energy but 
solid signal to downconverters in Unit 50. The downconverted signals are returned 
—to the main station equipment via microwave or cable links. These signals are split 
(power dividers), separated infrequency by channel (mixers), and detected. The 
digital output signals from the detectors are connected to Unit 30 for verification of 
the ground portion of the forward link transmitted signals. Unit 50 costs are not 
included in the DHMS costs. 

6.4 DOWNLINK SYSTEM 

The downlink system (Unit 60) contains downconverters, microwave links, 
splitters, and mixers for all return link signals. These are shown in Figure 2-1. 

All Unit 60 elements are backed up (redundant). The unit inputs are from the antenna 
systems, and test system (Unit 110) inputs are also assumed. 
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Unit 60 outputs connect to receivers in Units 70, 80, and 90 that handle the LDR, 
TDRS/orderwire, and MDR data channels, respectively. Control and monitoring of 
Unit 60 equipment can be performed by the DHMS. 

6.5 ANTENNA AND RF/IF UNITS SUMMARY 

Although some monitoring and control points in Units 40, 50, and 60 have been 
assumed that would be handled by the DHMS, costs for equipment in these units have 
not been included in the DHMS costs. Redundant equipment is assumed in Units 40 
and 60, but not in Unit 50. Therefore, single points of failure do exist in Unit 50. But 
this unit does not handle the forward or return link data for users or the TDRS OCC. 

The three units interface to the DHMS equipment at several points. Therefore, 
it was necessary to consider them in the development of the baseline DHMS. 
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SECTION 7 - LDR DOWNLINK SYSTEM 


7. 1 GENERAL 

The LDR downlink system, Unit 70, is composed of 24 identical AGIPA channels 
and is described in this section. Each AGIPA channel receives eight modulated RE 
signal streams from the downlink system (Unit 60) or the test system (Unit 110). The 
channels are controlled by individual computers directed by the control system, A.= - 
capacity for 20 users is provided, and user data are formatted and sent to the NASCOM 
interface system. 

Initial AGIPA channel design handles four standardized data rates within a range of 
0. 5 to 10 kbps. It is assumed that the data bit transitions are related to an integer number 
of PN code chips and the return link PN code synchronization pulse. (This facilitates data 
clock recovery. ) 

Standardized data rates above 10 kbps could be handled to about 30 kbps without 
major cost or performance impacts on the channel design. However, decreasing the rate 
below 0,5 kbps can affect the channel cost and performance because of the circuitry used 
to determine the Doppler frequency during signal acquisition (a discrete Fourier transform). 
'Decreasing the rate necessitates faster circuitry (or parallel circuitry) that would signifi- 
cantly increase the channel cost. 

The channel characteristics described are for the initial AGIPA channel design. A 
modified AGIPA concept was also considered, and is discussed in this section. 

7.2 AGIPA CHANNEL OPERATION 

A simplified block diagram of the AGIPA channel subsystem is shown in Figure 
7-1. The subsystem is composed of three subunits: the control system interface (Unit 
72), the AGIPA channel signal processor 1 (Unit 73), and the channel computer (Unit 74). 
(Unit 71 is the LDR user NASCOM switch that completes the subunits making up Unit 70. ) 


1 Includes the Viterbi decoder cost in Table 2-3 entries. 


7-1 




i 

i, 

* 



i. 

fi 









PA Chi 


l signal processor (acspi 


NATION RATE 500 TO JO. 000 BITS PER SECOND 


PN CODE AND CARRIER TRACKING CIRCUITS 


SYMBOL CLOCK TRACKING 


STATUS CONTROL 

| SEARCH | [~ RATE “J 
PN LOCK ADJUST 

I CARRIER LOCK 1— J 


ANALOG PROCESSOR 
CIRCUITS 


[SAMPLE SIGNAL SELECTl 


1 


« 9 - 


NTERFACE (CONTROL, STATUS, MEASUREMENTS) 


Dfill-C 


UNIBUS 



DIGITAL 
RANGE AND 
RANGE RATE 


SYMBOL DETECTOR 
3-BIT QUANTIZATION 
I St O CIRCUIT. 


TRANSMIT PN 
. SYNCHRONIZATION 
PULSE 
■TIME (48 BITS) 


[DATA, CLOCK! 

VITERBI DECODER (VDI 
R = V4 K « 7 


(SIGNAL PRESENT. BYTE SHJFT CONTROL? 


DR11-C tH MESSAGE BUFFER SYSTEM 


, LOR USER 
NASCOM SWITCH 



3 



1 DR11-B 

1 


DR11-C 


DR11-B 


I & D - INTEGRATE AND DUMP 

DRll-B/C- DEC INTERFACE CAROS 
PN - PESEUDONOISE 


PERIPHERAL UNIBUS 
SYSTEM 3 


PERIPHERAL UNlSUS 
SYSTEM 4 
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Assignment of a channel to support a given user’s spacecraft is provided by the 
control system. It indicates which TDRS (No. 1 or No. 2) signals are to be input, the 
spacecraft PN code, a priori phase and amplitude settings, and the expected data sym- 
bol rate (one of four selectable rates) that are scheduled to the channel computer. The 
control system also sets the NASCOM switch to connect the channel output to 1 of 20 
communication inputs to the NASCOM interface. 

Actual switch control within the AGIPA channel signal processor (ACSP) is per- 
formed by the channel computer. The computer also uses the initial phase and attenua- 
tor settings to adjust the phase and amplitude (p&A) circuits (weighting network) for 
initial signal reception. Modulated signals flow through the P&A circuits to the PN code 
and carrier tracking circuits. A code and carrier search are initiated. After acquisi- 
tion the channel computer adjusts the variable P&A circuits to optimize the received 
signal to interference ratios. 

User symbols are connected to the Viterbi decoder. It obtains forward error 
correction code lock and outputs data bits to the channel computer. Upon computer 
recognition of the telemetry data frame synchronization, the computer accepts digital 
R&R data from the ACSP. The tracking data are sent to the control system for trans- 
mission to GSFC. Chamiel status is also connected to the control system for moni- 
toring purposes. 

The control system centrally directs the LDR downlink channel operations. When 
handover times are recognized, a second AGIPA channel is set up on the other TDRSs 
signals. After telemetry frame lock is maintained through both AGIPA channels for a 
specified time, the second channel’s data are connected to the same NASCOM input 
port as was used for the first channel’s data output (a data loss does not occur). A drop- 
out of several seconds in the user’s data does occur upon TDRS handover, when the forward 
and return links are reacquired through the different relay satellite. 

The preceding discussion has provided an overview of the LDR downlink system's 
operation. The following paragraphs contain more detail on the AGIPA channels. 
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7. 3 LDR COMPUTER SYSTEM 


The LDR computer system is made up with 24 PDP 11/05 computers. Each com- 
puter controls one AGIPA channel and performs the following functions: 

© Frame synchronizes user telemetry data. 

© Blocks data into NASCOM messages. 

© Controls the channel phasors and attenuators (AGIPA pointing). 

© Programs the PN code generator. 

© Programs the bit rate. 

© Outputs blocked messages, including header information to users over the 
discrete user NASCOM link, 

© Outputs blocked frames, including header information to the control system 
for backup storage, 

\ 

© Takes AGIPA status and transfers this status to the control system. 

© Takes R&R data for the assigned user channel. 

• Communicates with the LDR control computer subsystem. 

Figure 7-2 shows the AGIPA computer software system processors that would be 
duplicated for each computer. Only one program would be developed for the computers. 
However, special user requirements, to a limited degree, could be implemented in the 
software if necessary. This modified operation would require a program transfer to the 
AGIPA computer rather than just the particular user’s control and data parameters. The 
programs would be stored on the disk systems in PI and P2. 

7,4 AGIPA CIRCUIT OPERATIONS 

A LDR AGIPA channel is composed of the elements that optimize the signal to 
noise ratio for the received signal. Eight input signals from the four element horizon- 
tally and vertically polarized antenna array on the TDRS are selected via a nine-pole 
triple-throw switch (see Figure 7-3). Three positions are available for TDRS No. 1, 
TDRS No, 2, or a test input. The ninth pole is for switch verification. Each of the 
eight channels is divided into two paths, one to the P&A weighting network and the other 
to a single-pole eight-throw solid-state switch. 
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The P&A network is the heart of the AGIPA. By varying the relative phases and 
amplitudes of the eig'ht input signals with respect to one another and then combining 
them, a directional antenna beam is formed. The phase is variable over a 360-degree > 
range, and the attenuation over a 20-dB range. Each variation is controlled by an 8-bit 
word from the AGIPA computer. The eight attenuated and shifted signals are summed 
to form a composite received signal. This signal is used in three areas; the analog pro- 
cessor, the carrier tracking loop, and the PN and symbol clock tracking loop. 

The analog processor consists of six detector channels. Two of the channels are 
used to detect the signal power and noise power in the composite signal (sum of the 8 
input streams). The other four channels provide a capability to measure the inphase 
(with respect to the signal portion of the composite signal) and quadrature parts of the 
signal and the noise components of one of the eight input signal streams. The single-pole 
eight -throw switch under control of the AGIPA computer is used to select the signal input 
for the analog processor. The six analog processor channel outputs are applied to a 
second single -pole eight-throw switch. 

Under computer control one of the six processor channels is connected to an 

analog— to— digita 1 converter (ADC). The ADC digitizes the analog measurements 
and interrupts the computer when a measurement is completed. Based upon the 
digitized samples from the analog processor, the phase and attenuation adjustment 
values are calculated to optimize the signal-to-noise ratio. If these values differ from 
the previous ones they are sent by the computer to the P&A network via the con- 
trol interface. The P&A networks, summer, analog processor, ADC, AGIPA com- 
puter, and control interface form the closed-loop AGIPA system. 

The second use for the composite signal is in the carrier tracking loop. It is a 
Costas Loop. Carrier and PN phase acquisition are aided by using a discrete Fourier 
transform to compute the Doppler offset frequency. Inphase and quadrature components 
of the low pass (peak Doppler frequency cutoff) filtered signal are sampled and digitized 
using 3-bit ADCs. The sampling rate is approximately equal to twice the peak of the 
Doppler frequency shift. Power coefficients are calculated at frequencies equal to the *' 
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inverse of the symbol duration, a new calculation being performed during each symbol 
interval. If the value of any coefficient does not exceed a predetermined threshold the 
PN code generator is retarded one-half chip interval. When the code generator is 
phased within a half chip interval of the PN sequence phase of the received signal, at 
least one of the frequency coefficients will exceed the threshold. The largest value is 
assumed correct, and it is converted to a proportional analog signal. This is used in 

t 

the frequency synthesizer to generate the IF plus Doppler offset reference for the 
carrier tracking loop. With the Doppler offset contained in the reference frequency, 
the mixer output is filtered by a second narrower low pass filter, proportional to the 
symbol bandwidth, to extract the symbols and to precisely track the carrier frequency. 

The PN code generator is identical to that on the particular user spacecraft. It 
produces Gold code sequences, and the code is programmed by the channel computer 
for each user spacecraft supported. 

A PN code acquisition search requires about 2.3 minutes on the average for a 

1-Mbps chip rate and a code repetition rate of 7.4 per second‘d when the encoded data 

rate is 1 kbps (this is the worst-case average PN code acquisition time based on a 0.5- 
2 

kbps data rate). The timing source for the PN code generator is derived from a tracking 
loop operating on the third component of the composite signal. Because the symbol clock 
is x’elated to either the PN chip clock or the PN sequence synchronization pulse, or both, 
it is also derived from the PN code clock tracking loop. 

Encoded symbols and their clock are connected to the Viterbi decoder. It in turn 
supplies decoded data bits to a serial-to-parallel interface for input to the AGIPA computers. 
Because the computer performs frame synchronization, it determines whether the bits 
being sent to it are aligned correctly. If the alignment is off (i. e. # the first bit in the 


Only the long code (11 sequences of 2047 chips on the forward link) is assumed to be 
used. The TDRSS Study Group is considering using a shorter code that would decrease 
the search time to acquire PN code lock. 

Data are encoded with a rate 1/2 convolution code increasing the transmitted data rates 
by a factor of two. r;_ j / 
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frame pattern is not the first bit of a 16 -bit word), the computer commands the interface 
to change it. At the time that the interface responds some data from the previous word 
are repeated. An interrupt is generated as each 16-bit word in the interface is completed, 
and the real-time clock value is stored. The computer reads the time if the interrupt 
corresponds to the first word in a frame or some predetermined number of frames. 

Blocked and time tagged data from the computer are supplied to a double NASCOM 
block-buffered-parallel-to- serial interface. When a block transfer to the interface is 
completed a data ready signal (data request) is presented to the NASCOM network via 
the NASCOM user switch. NASCOM replies to the switch with a data set ready, clear 
to send, and transmit data clock. These are combined to produce a gated clock for 
transmission of the data from the interface. 

The NASCOM user switch is composed of 20 switch cards, each handling the 
interface between one of the NASCOM lines and any of the 24 LDR downlink channels. 

Each switch card is programmable by either of two interfaces via peripheral Unibus 
systems 3 and 4. The interfaces are independent, and a failure in one does not affect 
the other. 

In addition to the detection and transmission of blocked message data to NASCOM, 
the AGIPA channel also computes the range and rate of change of range of the user 
spacecraft. Range is measured by computing the time from the transmission of the up- 
link PN code synchronization pulse to the reception of the downlink PN synchronization 
pulse, A counter with a 40 -MHz input clock resolves the total round trip delay to +25 
nanoseconds. This delay includes many sources (transponders, etc.) in addition to the 
user spacecraft range for which compensation or calibration factors must be supplied. 

Range rate can be computed in a number of ways. One way, which provides an 
average value centered in time at about the time of the uplink PN code synchronization 
pulse, is to count the cycles of Doppler frequency between the uplink and downlink PN 
code synchronization pulses. Resolution to fractions of a cycle may be obtained by 

1 It is assumed that frame lengths will be an even multiple of 16 bits in length. 
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multiplying the Doppler frequency offset. This value and the range measurement are 
input to the channel computer. The computer time tags and formats each R&R sample 
and then transmits the sample to the control system for further handling, 

7.5 AGIPA CHANNEL MODIFICATION 

A modified AGIPA concept has been considered and its costs estimated as a 
delta (change) to the DHMS cost. It is to have 30 modulated IF input streams. Three 
signal sources are maintained as before from TDRS No. 1 and No, 2 and the test system. 
Additionally, any data rate between 0.5 and 32 kbps that provides an integer relation to 
the PN code synchronization pulse can be processed in the AGIPA channel rather than the 
four particular rates considered for the basic LDR downlink system. 

The modified system operates the same as the basic system. However, 30 sets 
of individual and composite signal values are sampled rather than the basic eight sets. 

The modified system uses the same computer and Viterbi decoder as before, but an 
additional computer output channel is provided to the LDR user data recording system. 

The recording capability is removed from the control system and is located in Unit 70. 

Because the modified AGIPA concept is for use with S-band return link frequen- 
cies, the attenuators in the weighting network may not be needed. (Note that the S-band 
signals must be downconverted to a VHF IF before entering the AGIPA channels. This 
conversion would be performed in Unit 60.) The phasing and attenuator weighting 
network becomes expensive, compared with the basic network, because of the additional 
22 signal circuits. Removing the attenuators if they are not required provides a significant 
cost saving. 

7.6 LDR SYSTEM SUMMARY 

The basic elements composing the LDR downlink system have been described. 
Twenty-four discrete AGIPA channels are provided that are centrally directed by the 
control system. Because a maximum of 20 users are expected, 4 channels are always 
available for TDRS handover and to be switched to handle a user’s data if the assigned 
AGIPA channel fails. 
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Continuous data handling is provided about 85 percent of the time for earth-orbiting 
LDR spacecraft. This time percentage results because of the tracking coverage supported 
by the active TDRSs. During TDRS handover, a dropout in the users’ data will occur for 
several seconds because the spacecraft and AGIPA channel reacquire PN code lock through 
the different supporting satellite. 

A consistent user’s data channel to the NASCOM interface is supplied upon hand- 
over or malfunctioning channel operations. The NASCOM user switch is the only Unit 
70 subunit not backed up. However, it is designed modularly so that if a segment fails 
the entire switch is not disabled representing a single point of failure in the downlink 
system. 

A modified AGIPA concept was briefly considered. Estimated delta costing 
is made in Section 2, The new concept operation is essentially the same as the basic 
system operation except that 30 modulated signal streams are manipulated instead of 8. 
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SECTION 8 - TDRS AND ORDERWIRE DOWNLINK SYSTEM 


8.1 GENERAL 

The TDRS and orderwire downlink system is considered the simplest in the 
DHMS. This Unit 80 element basically is two parallel data handling channels. Each 
channel operates independently of the other and is capable of supporting the TDRS 
housekeeping telemetry data synchronization and formatting for the three satellites. 
Orderwire (OW) event signals are formatted with the housekeeping data. The system is 
discussed in this section. 

8.2 SYSTEM DESCRIPTION 

Parallel housekeeping data channels are input to the TDRS/OW system from each 
of the three TDRSs. Orderwire event signals (bilevel) are also received in parallel 
from the on-station TDRSs. Figure 8-1 shows the system layout, including its 
interfaces to the control system and NASCOM, 

The TDRS/OW computer system uses two PDP- 11/40 computers, one as a prime 
and one as a backup unit. Each computer is capable of completely handling all three 
TDRS downlink systems. The software system performs the following tasks in 
supporting the TDRSs; 

© Independently handles under interrupt control each TDRS telemetry bit stream 
and performs frame synchronization for the data. 

• Blocks each of the TDRS telemetry streams into separate NASCOM messages, 
including the necessary header information. Then either outputs to NASCOM 
over three discrete links or outputs to TDRS main computer storage 
system (C3), 

© Processes all incoming orderwire bilevel signals. 

« Processes TDRS telemetry data and converts them to engineering units for 
display on the CRT keyboard consoles via Unit 20 operation. 
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Figure 8-1. TDRS and Orderwire 
Downlink Data System 
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Each TDRS downlink telemetry stream would be decoded so that status of the 
satellite subsystem can be displayed on different CRT pages. Subsystem data that 
might be processed are power, communications, data processing, stabilization, and 
control. Figure 8-2 shows the processors that would be implemented for each TDRS 
computer system. 

Under control system direction both TDRS/OW computers supply data messages 
to the NASCOM interface. As shown in Figure 8-1, six lines are used where the three 
from each computer provide data from each satellite. Therefore, multiplexing of the 
housekeeping data is not done. 

Single rate bit synchronizers are used to develop the TDRS data clock and shape 
the data for input to the computer interface circuits. These circuits provide a serial- 
to-parallel data conversion. When 16 bits are assembled an interrupt is generated to 
the computer, and the data enter a buffer space. Frame synchronization is performed 
after which the interface circuits are controlled to input 16-bit words that can be used 
without repeating the framing operations. 

Only one data stream is input from each TDRS. The interface circuit on the re- 
dundant receiving system is disabled by the computer. 

The OW inputs are digital (bilevel) events. They are also redundant. A logic One 
is interpreted as a request for service. Otherwise no action is taken by the system. 

If OW service is requested the event signal is indicated in the TDRS data sent 
to the TDRS OCC. Also, the control system is notified via peripheral Unibus systems 
3 or 4. The control activates a GS alarm as a backup in case the event went undetected 
at the OCC. 

This brief description indicates the basic TDRS/OW operations that are expected. 
If the PD P-1 1/40 computers are required to perform the complete computation house- 
keeping data handling for the TDRS OCC, the system easily can be expanded. Frame 
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Figure 8-2, TDRS/OW Software Processors 














synchronizers would be added to relieve the computer of the framing tasks. Additional 
control system interfaces would be used. Thus, almost the entire computer capacity 
could be devoted to OCC tasks. 

In summary, little detail is provided for the TDRS/OW system because the TDRS 
data housekeeping tasks were not defined in detail. The costed system should be ex- 
pected to handle any GS requirement, however, and it is redundant and capable of simple 

expansion if required. 



SECTION 9 - M DR /SHU T T L E DOWNLINK SYSTEM 


9. 1 GENERAL 

The MDR/shuttle downlink system (Unit 90) is described in this section. It is the 
most costly DHMS unit because it contains a disk storage capability for up to 2 hours 
of data entering the system at a 4 -Mbps rate. 

There are 10 data handling channels that support the requirements of the MDR 
users, both for real-time throughput, and storage and playback at a future time. This: 
minicomputer subsystem is made up of five PDP 11/45 computers, each having the 
ability to handle two 1-Mbps data input streams, th roughputting these data streams to 
NASCOM or storing one and throughputting one. The Unit 90 system is controlled by 
the configuration control software system. 

Although there are 10 channels, the channels are not independent because two use 
one computer. If one computer fails then two channels are inoperative. An exotic 
contingency switching arrangement was initially considered for the system to maintain 
a high system availability. However, a preliminary availability analysis^ indicated that 
this was unnecessary and could possibly degrade the system availability. Therefore a 
straightforward design approach was taken, and most of the switching circuits were 
eliminated. 

Two special channels are provided for shuttle data handling. They use computers 
93D and E. It is assumed that the shuttle return link will have word synchronization 
patterns in the telemetry data, not bit or distributed synchronization patterns. The shuttle 
data frame is synchronized and demultiplexed by computer program, stripping out the delta 
modulated voice information that is converted to an analog format. The remaining shuttle 
data are blocked and provided to the user over NASCOM links. Return link voice is also * 
sent to the user and is available at the GS as a backup in case of a MCC contingency. A 
special shuttle data handling unit independent of the MDR computers is also described in 
this section. 

Appendix A. - ^ ^ r 
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9 .2 MDR COMPUTER SUBSYSTEM 


The computer system is made up of five PDP 11/45 computers, each as a multi- 
processor configuration with two Unibuses. Each system includes a set of the following 
periphe ral ' equipme nt: 

o LA30 DEC writer 

6 Central processor memory management unit 
9 Real-time clock 

9 Bootstrap loader 

o Three 8000-word core memory units 

• A PDP 11/45 and a PDP 11/05 CPU 

e One solid-state memory control unit 

9 MOS memory block of 8000 words 

e Core memory for Unibus number 2, 8000 words. 

Four disk storage systems are also included. They have the capacity to store up to 
8 hours of data received at a 1-Mbps rate, or 2 hours if filled at a 4-Mbps data 
rate. 

All MDR user data from the frame synchronizers are blocked, message header 
information is added, and then the messages are output to NASCOM in real-time or 
stored on a disk system for later playback. This process is under the control of the 
configuration control computer. For the real-time data the assumption is made that 
the NASCOM communication link will be sufficiently fast so that data being processed 
will be taken from the system buffers as fast or faster than they are being put into .the 
buffers. Figure 9-1 shows the main processors that would be developed in software 
for the MDR computer subsystems. A simplified diagram of the computer subsystem 
hardware is provided by Figure 9-2. 
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Figure 9-1. MDR Computer Software System 
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The MDR/ shuttle downlink processing equipment is shown in Figure 9-3. There 
are five independent dual-channel groups. Each group consists of two processing chains 
designated real-time (RT) and playback (PB) in the figure. These two chains do not have 
to be used for RT and PB as show nor do they have to be servicing the same MDR user. 
To support four MDR users, each capable of simultaneous RT and PB transmission, 
requires four dual-channel groups, and redundancy is provided with the fifth. 

A nine-throw single-pole normally open wideband solid-state switch couples one 
of the nine demodulator outputs from Unit 60 to the bit synchronizer. The bit synchro- 
nizer derives bit timing from the input signal producing both data and clock as inputs 
to the frame synchronizer. Eight of the 10 bit synchronizers make single bit (hard) 
decisions on the polarity of the data symbols. Two make three bit quantization (8 level 
soft) decisions. These soft decision devices supply inputs to the soft decision rate 1/2 
Viterbi decoders required for shuttle. The fourth and fifth dual-channels have the choice 
of either Viterbi decoder clock and data or bit synchronization clock and data [most 
significant bit (MSB) of the 3-bit quantization ] as the input to the frame synchronizer. 

The frame synchronizer searches for the telemetry frame synchronization pattern 
in the incoming data. This pattern can be up to 33 bits long. Frame length, frame 
synchronization pattern, and the number of bits in the pattern as well as various other 
controls are programmable. Data out are formatted in 16-bit words for parallel trans- 
mission to the MDR computers. 

When the frame synchronization pattern is found, a pulse occurs. This pulse is 
used to store the 16 least-significant bits (LSBs) of a real-time clock. The more 
significant bits of time are updated only when they change. Time is affixed to each 
incoming frame by having the synchronization pulse generate an interrupt for the 
computer and store the time in an interface buffer. The MDR computer reads the k 
time and inserts it into the output data formatted to NASCOM. 



: ancArol 

niels 


PERIPHERAL UNIBUS NO. 7 INTERFACE (DRI1-C) 


PERIPHERAL UNIBUS NO. 8 INTERFACE (OR1 J-CI 





ISE 1 

s 

Figure 9-3. MDR/ Shuttle Downlink System 

FOLDOOT^Pi 

t. 

(1 of 5 channels) 


9-6 














DIGITAL toONtTOH and CG-v f 
COMMON rofl ALL OUAL-CH -- 



fGLDQOT 



STATUS 

CONTROL 

& 

GATING 


STATUS 

CONTROL 

& 

GATING 


PCRlPHf « 


J 


STATUS 

CONDITIONING 


r 


READ/WRITE I 


DATA 


ADDRESS 


17 


L 




VERIFY 

CONTROL 


Of 

RE 


DOWNLINK 
DEMODULATOR ( 
OUTPUTS 



. DOWNLINK 
DEMODULATOR < 
OUTPUTS } 


,f 


□ 

L 

4 BIT 
SELECT 
REGISTER 

j 


J 


4 BIT 
SELECT 
REGISTER 




L- 


1 


30 BIT 
REGISTER 



1 



30 BIT 
REGISTER 

J 




INTERFACE 

FRAME 

[SYNCHRONIZER! 
CONTROL 


SP9T 

ANALOG 

SWITCH 

P8 


BIT 

SYNCHRONIZER) 
Pfi 


DIGITAL 

SWITCH 

FOR 

SHUTTLE 


FRAME 

SYNCHRONIZER! 
PB 


SOFT OECISION 
B-1/2.K=7 
VITERBI DECODER 
(RT/PBC N0.4&N0.5) 


PSV - PROGRAM STATUS VERIFICATION 
EMR - EMR TELEMETRY 
RT - REALTIME 
PBC - PLAYBACK CHAIN 

SHUTTLE E0UIPMEN7 COMMON TO DUAL-CHANNELS NO 4 AND NO 5 
(MDR DOWNLINK CHANNELS NO. 7 THROUGH NO. 10) 




Lr. 

1 


BUFFER DRIVERS i. 
118) 


.TO ADA 


•• s' 


* 

I 

I 




Programming of the MDR channel equipment (not the computer programs^) is 
performed from peripheral Unibus systems 1 and 2, The interface is bidirectional and 
is also used for verification of the program. Output data (write commands) from PI or 
P2 are divided into device address, function codes, and data. The four MSBs represent 
the device address; the next four, function codes; and the 8 LSBs, data. This format 
is used by the commercially available frame synchronizers. 

There are 16 addressable devices: 10 frame synchronizers, 5 dual-channel equip- 
ment groups (everything but the frame synchronizers) and the MDR user NASCOM switch. 
Control verification is performed by issuing read commands. The form of the data read 
into PI or P2 is 4 bits of address, 4 bits of function codes, and 8 bits of data. Issuing' 
read commands increments an 8 -bit counter, and the count is detected as address and 
function code bits. This gates the appropriate data bits on line, as well as being read as 
the 8 MSBs. An independent interface exists between the dual -channel groups and PI and 
P2. -- 

Interface to the MDR processor (PDP 11/45) is through a direct memory access 
(DMA) card with two 16-bit inputs (EMR“ unit 2763). One of the inputs is the 16-bit 
data word from the frame synchronizer, the other is the time of day clock’s 16 LSBs. 
Four of these DMA interface cards are in each dual -channel group, two for the data 
chains in the group and two for the data chains in the adjacent dual -channel group. 

The data output from the MDR computer are via a single 16-bit DMA interface 
(DRUB). Data are serialized in the NASCOM interface for transmission over the 
NASCOM links. This interface can double buffer a 1200-bit NASCOM block, and 
supplies a data ready signal as serialized data become available. Output in the form of 
delta-modulated voice signals is also provided on dual-channel groups 4 and 5 for the 
shuttle. 


These are entered into the MDR computers via an intercomputer channel from the con- 
trol system. 

2 

•EMR Telemetry. f 
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The NASCOM user switch is programmable by PI or P2 control to connect eight 
NASCOM lines to any of the ten possible NASCOM interfaces (2 per dual-channel group). 
There are eight switch cards, one for each NASCOM line. They accept a data set 
ready, clear to send, transmit clock, and supply data and request to send to the 
NASCOM interface system. 

9.3 NONCOMMON MDR EQUIPMENT AND INDEPENDENT SHUTTLE UNIT COST 

Figure 9-3 shows some equipment that is not common for each dual-channel. — 

The DBMS digital monitor and control (DMC)unit can send or receive 8 bits of data and " 
interface them to the control system through P7 or P8. Up to 256 addresses are avail- 
able to control and monitor any GS equipment connected to the DMC unit. 

The shuttle devices (soft decision bit synchronizers, Viterbi decoders, and 
dual -delta voice demodulators) are duplicated in dual-channels 4 and 5 (MDR downlink 
channels 8 and 10). A computer program separation of the voice data from the shuttle 
data stream is costed in Table 2-3 (Section 2, DHMS pricing). 

Should a computer-independent shuttle return link system be required, a special 
data demultiplex unit must be designed and built. Procurement (development and 
fabrication) costs for this demultiplex unit are estimated at $11K each for two units. 

Monitoring and control would be effected through the DMC unit via control system 
operations. The special demultiplexer would use the soft-decision bit synchronizers, 

Viterbi decoders, and the delta-demodulator dual-units already costed in Unit 90. 

A special cost delta of $22K for hardware and $19. 8K for installation, totaling $41. 8K, 
would be added to the total DHMS installed cost estimate for two independent systems. 

9.4 MDR SYSTEM SUMMARY 

A reasonably detailed description of the MDR/ shuttle downlink system has been 
presented. The system provides prime and backup data handling channels for eight 
simultaneous telemetry streams, each received at a data rate up to 1 Mbps (all equip- 
ment can operate up to 1. 2 Mbps if required). Two backup channels are available in 

✓ 

the five dual-channel computer systems. - ^ ^ ' 
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Disk data storage units are provided for holding user data at times when the GS 
real-time output communication rate would exceed the NASCOM link capacity or when 
the links were inoperative. All operations are controlled and monitored by Unit 20. 

Special DMC equipment is included, and a provision for prime and backup shuttle 
return link data handling is incorporated into the MDR user system. A delta cost is 
provided to handle shuttle data independently of the five minicomputer subsystems if 
desired. (This delta cost is not included in the Section 2 prices. ) 
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SECTION 10 - CONSOLES AND DISPLAY SYSTEM 


10.1 GENERAL 

Unit 100, the consoles and display system, is discussed in this section. This 
DHMS unit provides the man/machine communication interface for the GS’s maintenance 
personnel. Three identical consoles are considered necessary and they operate with 
the control system via two Unibus systems for redundancy. 

10.2 SYSTEM DESCRIPTION 

The consoles and display system is composed of three identical elements each 
having four subunits. These subunits are: 

9 GO/NO-GO display panel 

© CRT display \ 

• Hardcopy device 

• Command and control panel 

Basically, the GO/NO-GO display panel in each console should alert GS personnel 
of any station malfunction. The malfunction should be identified to the level of a sub- 
unit or communication link. An audio alarm is incorporated into the panel to alert the 
personnel because it is not considered necessary to have them continuously monitor the 
console activities. Figure 10-1 shows a possible panel layout. 

The CRT displays contain three controllers and three screens, one for each 
console. A copy of any CRT page can be made with a hardcopy device that reproduces 
the identical CRT page contents. Each console has a thumbwheel control to provide a 
selection of up to 32 different CRT pages. The page format would be preprogrammed 
and output from the control system. The following would be typical types of page 
displays: 

« Command and command verification status showing command 
failures and noncomparing bits 

© LDR equipment assignments and status 
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e MDR equipment assignments and status 
© TDRS equipment assignments and status 
© R&R data, equipment assignment and status 

e Operational NASGOM data links 

© Manual command and command group displays 

© Equipment status 

© Configuration 

e Schedule assignment callup 

e Event page of configuration changes, equipment failures, equipment 
back in operation, messages from GSFC, etc. 

© Changeable input pages for predefined status and monitor items 

Each keyboard would provide all control inputs to effect configuration changes, 
manual commands, diagnostic system checks, simulator inputs and other ground- 
related controls. 

The command and control panel provides thumbwheel selection for CRT page 
displays, pushbuttons to activate processors that are required frequently, and thumb- 
wheels for selecting group commands which then would be loaded and executed via 
pushbuttons. A possible panel layout is shown in Figure 10-2. 

A more complete GS equipment and operational procedures knowledge than is 
now available is necessary for a refined consoles and display system design. The 
preceding system description shows a pi'eliminary consideration of the man/machine 
GS interface. This interface is significant because the consoles can be used to backup 
some operations in contingency situations that are normally provided by the MCCs 
and the TDRS OCC. 
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SECTION 11 - TEST SYSTEM 


11.1 GENERAL 

The test system. Unit 110, has received only minimum consideration. It is 
described briefly in this section. Much greater detail is necessary for this system; 
it would be developed during a final DHMS design. 

11.2 SYSTEM DESCRIPTION 

Redundant telemetry data simulators, controlled through peripheral Unibus sys- .. 
terns 1 and 2, are in the test system. They can be programmed to duplicate the frame 
synchronization pattern, and special (known) data can be inserted into the telemetry 
data sections of the frames by the simulation units. A planned test frame, simulating 
the basic characteristics of the LDR and MDR users' telemetry data, can be injected 
into the DHMS for test purposes. 

In particular, test data would be generated whenever the station schedule required 
an MDR channel to be established. The data would be modulated onto an appropriate 
IF signal and input to the downlink test mixers. Receiver tuning would be accomplished 
automatically, as would other MDR-controlled actions. A test computer program in the 
MDR minicomputers would compare the incoming test data with their expected values. 
Excessive data errors or nonreception of data would indicate a channel failure, and a 
backup channel would be automatically established. 

The spare LDR (AGIPA) channels could be similarly checked out. The monitor 
points within the DHMS should provide an indication as to where the test signal was 
being blocked. This information would be provided through the display unit to the sta- 
tion maintenance personnel who would then perform detailed tests on the suspect equip- 
ment units. 

As development of the GS continues, special software routines would be developed 
to test all automated station units. The control system computers would exercise the 
equipment (not supporting current user activities) in an online mode for the special or 
normal preventative maintenance operations. 
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Although not currently costed, other computer-controlled test equipment, such 
as variable-power IF signal generators that could be modulated with the simulator’s 
data, special power meters, and bit error rate counters, would be necessary for the 
station. These items could be added, however, after the basic station equipment had 
been installed and checked out manually. 


SECTION 12 - MODIFIED DHMS CONFIGURATIONS 


12.1 GENERAL 

The previous sections describe the systems composing the baseline DHMS com- 
pleted during the Phase I study. We now begin a discussion of the MDHMS considerations 
investigated during the Phase II study effort. 

Basically the MDHMS brings together an operational capability to direct and 
manage the TDRSS. Functions of the DHMS and the OCC are implemented in one com- 
posite hardware/software system. ^ Two approaches to perform these MDHMS functions 
were carried to preliminary systems configurations so that we could estimate system 
cost. . 

The first approach was to modify the baseline DHMS control system with a com- 
posite control system (CCS) to provide the capability to perform combined DHMS and 
OCC functional operations. This MDHMS is Configuration I, and two costs were 
developed using, (1) the PDP 11 minicomputer series, and (2) Varian produced mini- 
computers. The second approach was to develop MDHMS configurations that use midi- 
computers, and all -midicomputer Configuration II was costed using System Engineering 
Laboratories’ (SEL’s) SYSTEMS 86 computers. In similar fashion, Configuration III 
was developed with both minicomputers and midicomputers. To estimate costs, the 
Xerox Sigma 9 computer represented midicomputers, and the Xerox 530 and System 
Control Units (SCUs) represented the minicomputers. 

This two-approach attack was performed to develop cost information showing 
(1) the impact of collocating the OCC and DHMS functions within one hard ware /software 
system, and (2) the variation of MDHMS costs using different configurations and manu- 
facturers’ computer hardware. All MDHMS configurations execute the same basic 


Note that precision orbit and attitude determination programs, and orbit and attitude 
maneuver planning programs are not included in the MDHMS software. These orbit t 
and attitude programs would be executed on the GSFC computers at the request of the "" 
TDRSS operations personnel. 
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applications software functions; therefore, only one MDHMS software cost was 
developed (this adds to the baseline DHMS software cost) - $0. 6M. However, the costs 
for the computer, data storage, and operations console hardware are based on esti- 
mates from each of the four manufacturers. Hardware costs are given in the introduc- 
tory discussion of each configuration. 

The following paragraphs describe the MDHMS functions and software require- 
ments to perform the TDKSS OCC operations. A brief introduction to the four hardware 
systems is provided, followed by a comparison of the systems and the conclusions 
resulting from the Phase II study effort. Sections 13, 14, and 15 present a more 
detailed description of Configurations I, II, and III, respectively. 

12.2 MDHMS FUNCTIONS AND SOFTWARE 

The MDHMS performs those DHMS functions previously described as well as 
those of the TDRSS OCC as described here. The functions are implemented via soft- 
ware (processor) control (i.e. , applications programs to be written for the MDHMS). 

The control software operates within the CCS made up with six minicomputers in Con- 
figuration I, three midicomputers in Configuration II, or two midicomputers for Con- 
figuration III, (Note midicomputers also perform functions other than control functions.) 

Four functional software areas are discussed. They are: 

• Command and Control Processors 

0 TDRS Telemetry Data Processing Processors 

@ TDRS Data Display and Control Processors 
e TDRS Procedure Control Processor 

Seven operator stations (consoles) are provided to operate the MDHMS. They are also 
outlined in the following paragraphs. 


^Specific programs to be developed for the MDHMS. 
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12.2.1 Command and Control Processors 


The functions of the command control are to input all configuration control com- 
mands, buffer and output all spacecraft commands, check verification of all commands, 
maintain a station schedule, control and monitor the Monitor Computer System, manage 
the storage of the LDR and MDR data, and control the NASCOM data links. The follow- 
ing processors are required to perform the command control tasks. 

12.2.1.1 Command Output and Verification Processor (COV) 

The purpose of the COV processor is to receive commands from the command 
processor, buffer these commands, transmit them to the correct TDRS, and check the 
returned command verification to determine if a ground loop failure occurred. Upon 
detecting a failure, the processor will output an error message to the user and oper- 
ator indicating the type of command failure detected. 

12.2.1.2 Command Processor 

The purpose of the command processor is to buffer commands received from 
operator prompts, procedure tapes, and attitude control commands, to check these 
commands for validity and ensure that none will endanger the spacecraft, then transfer 
the commands to the command output processor. Also, the processor will provide the 
capability of fabricating commands during real-time operation for any of the TDRS or 
user spacecraft. 

12.2.1.3 Configuration Control Processor 

The configuration control processor is to maintain control of all TDRSS equip- 
ment through the following tasks: 

1 

9 Execute real-time or predefined schedule configuration control commands. ' 


Commands to the TDRSs will normally be transmitted through the GS equipment when 
the TDRSs are in standby or on station orbits. During transfer orbit operations the v 
commands will be sent to the NASCOM switching system at GSFC for distribution to - 
STDN stations. 
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© Execute configuration control changes due to automatic system failure 
checks. 

' © Accept inputs from the monitor system on the status of all ground equip- 

ments. 

© Maintain a status table indicating whether a unit is degraded, usable, not 
available, or presently assigned, and if assigned, to which channel or link. 

9 Perform a simulator control check of each link before assignment to a user 
is made. 

q After all configuration changes, automatically update configuration status 
tables. 

© Alert operator personnel of degraded or failed equipment. 

9 Maintain a record of the TDRSS configuration. 

© Assign the MDR links, and maintain a directory of stored MDR user data. 

& Maintain a directory of stored LDR user data. 

12.2=1.4 Schedule Control Processor 

The purpose of the schedule control processor is to establish the support require- 
ments needed over a 24— hour period, to allow for changes to scheduled events, to be 
receptive to the need of satellite users, and to resolve conflicts as they occur. The 
tasks performed by this processor are: 

© Establish a 24-hour activity plan (with contingency options) and support 

schedule inputs from satellite users, TDRS orbital data, ground system con- 
figuration changes, precomputed MDR antenna pointing command sequences, 
and other user and TDRS commands. Changes to this schedule are to be 
performed offline. 
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© Establish a 2-hour activity plan to be maintained on the online system and 
updated as required in real time. 

e Output an integrated printout of the activity plan every hour or on demand. 

e Accept inputs of ephemeris for all user spacecraft and each TDRS from the 
GSFC orbit determination computers via a communication link. 

© Output telemetered attitude and position data for attitude determination com- 
putation. 

12. 2.1. 5 Antenna Pointing Processor 

This processor will generate the nominal slew/track antenna tracking commands 
for all MDR scheduled users. The ephemeris received from the GSFC orbit determina- 
tion group as well as the position of each MDR antenna will be input to this processor. 

12.2.1.6 NASCOM Link Control Processor 

The purpose of this processor is to control the command and control NASCOM 
links. Incoming messages from the GSFC are accepted on one or two 56-kbps high- 
speed communication links (one prime, one redundant). The incoming links contain: 

- (1) command data messages for LDR, MDR, and shuttle users, (2) schedule changes 
to be incorporated into the activity plan, (3) operational data messages, and (4) ephemeris 
messages. 

Outgoing messages are output on two 2.4-kbps NASCOM composite status links. 

The outgoing messages contain (1) command verification failures detected, (2) current 
system status, (3) users being serviced, and (4) problem status summary bits. 

12.2.2 TDRS Telemetry Data Processing System 

The telemetry data processing computer system functions are to control, process, 
display, printout, and distribute TDRS housekeeping telemetry data. Also, to control 
the assignment of LDR downlink AGIPA channels and either provide, temporary storage 
for up to 2 hours for each TDRSS user or have data throughput directly to the LDR ^ 
users. The following processors are required to perform the telemetry data processing 

tasks. 
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12.2.2.1 Data Acquisition Processor (DAP) 

The purpose of the DAP is to: 

o Accept telemetry data from all three TDRS, decommutate, validate, limit 
check, and distribute data to three separate data buffers. 

@ Maintain a history data tape of TDRS housekeeping data. 

® Block and transmit attitude data blocks in near-real -time to the GSFC 
attitude determination group via the communication links. 

© Maintain control of each LDR AGIPA downlink channel, store all required 
LDR playback data, output this stored data upon request to the NASCOM 
communication interface. 

• Block and process all range and range rate (R&R) data and schedule the 

playback of this data to the NASCOM interface on any three range and range 
rate data links. 

12.2.2.2 Telemetry Data Processor 

The purpose of this processor is to accept decommutated telemetry data from 
the Data Acquisition Processor and perform the following tasks: 

a Select particular telemetry data items, process them and output them to 
displays and printouts, 

a Maintain current status of each satellite. 

© Provide options to print and/or record raw data. 

@ Select telemetry data items from each satellite, average these values over 
time, and store the averaged values in a special data buffer. 


1 

During transfer orbit operations, the TDRS telemetry data will be accepted in standard 
formatted messages from the GSFC NASCOM switching systems. 
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@ Maintain and update data files of current calibration data, coefficients, 
engineering descriptors, special engineering equations, and telemetry 
data items averaged over time. 

© Provide the capability of sequentially printing in real time any limit failures, 
changes in equipment status, commands being output, operator messages, 
and system-detected failures. This same information will be blocked and 
stored on a history tape. This capability provides a complete history of 
spacecraft operations. 

e Snapshot telemetry data of each satellite subsystem; examples are: power, 
communications, data processing, and control system snapshots. 

0 Data plotting printouts of spacecraft parameters. 

• Sequential printout capability of up to 12 data items, including telemetry 
data, equations, and system -calculated items, such as attitude determina- 
tion data; all are to be printed sequentially with each page containing a 
header and each data row containing GMT time, spacecraft time, and the 
data items requested. 

o Provide composite status of each satellite for display on each GO/NO-GO 
status panel and the TDRSS status display board (SDB). Figure 12-1 shows 
an example of the SDB. 

a Maintain a data history file for real-time access which will permit opera- 
tions personnel to call up data for trend analysis and TDRS performance 
evaluation. 

12. 2. 3 TDRS Data Display and Control System 

The TDRS Display and Control System is to be designed to give an overview of 
the complete TDRSS operations. This processor will drive multiple operator consoles, 
consisting of CRT displays, keyboard, and command control input panels. The display 
and control processor executing on the MDHMS computers will provide the following 

capabilities; 
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Figure 12-1. TDRSS Status Display Board (SDB) 














© Drive a CRT display system with a fixed header area of four lines and an 
assignable page of 16 lines for each display device. The fixed area will 
contain header information, such as time, operator messages, failed limit 
information, commands being manually generated, and group commands 
being requested. The assignable page areas will provide the following dis- 
play pages: 

© Power data 
e Communication data 
e Thermal data 
© Attitude data 
© Propulsion data 
© Event data 
© Command group . 

© Limit 
« Schedule 

• Variable telemetry format. 

9 Accept operator prompting from keyboard consoles for controlling the real- 
time and offline TDRSS operations. All manual commands, special attitude 
control commands, instructions to remote operator station, initializations, 
reassignments of data limits and CRT variable page options, and all other 
operational inputs will be accepted by the computer, checked for validity, 
executed or responded to with an error message in cases of erroneous inputs. 

& Support a control input panel providing capability for quick reaction response 
to operational procedures or problems. The control panel will contain: 

9 Thumbwheel switches for the selection of group commands and CRT 
page displays 

© Pushbuttons for procedure and/or schedule controls, for command 

execution and command verification recycling, and for data processing 
control. 
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Five operational consoles provide the man/machine interface for the TDRSS. A 
concept for the OCC layout is shown in Figure 12-2. In addition, two GS consoles are 
provided, Figure 12-3, for maintenance and backup. The GS consoles would be lo- 
cated in In area physically separated from the OCC area. A11 seven consoles are driven 
and serviced by the control computet s. 

12,2.4 TDRS Procedure Control Processor 

The TDRS procedure control processor will provide operational personnel with 
a mechanism for planning and executing engineering spacecraft tests and scheduling 
procedure sequences in «n orderly manner. It will provide the capability to accept 
procedure statements from a digital tape recorder or a card reader, where each pro- 
cedure statement has a program name followed by a set of input arguments. Each pro- 
cedure statement will perform a particular function. Procedure statements to be 
provided are as follows: 

e Analog value testing (testing for greater than, equal to, or less than) value 
indicated 

@ Status test (determine whether a bit is a 'one' or 'zero') 

e Jump ’n’ number of lines 

• Maintenance and editing of procedure tapes. 

Any of the system processors can be incorporated into a procedure, such as spacecraft 
commands, printouts, limit checks, CRT page format changes, or any other control 
inputs which may be required during satellite operations. 

This processor accepts inputs from procedure tapes via peripheral devices, such 
as digital tape recoi'ders or card readers. Each statement on the procedure tape is 
executed sequentially and activates some output peripheral device, such as a printer, 
display, card reader, magnetic tape, or performs a specified control function. 


12-10 



12-11 


TDRSS STATUS DISPLAY BOARD 



m 


[I 


3 

GO/NO-GO 

STATUS 

CRT 


COMMAND 

CONTROL 

PANEL 

• 

INTERCOM 

PANEL 

KEY- 

BOARD 


TDRS CONSOLE 1 



4 

. 

5 

— 1 

6 



7 


8 


9 

GO/NO-GO 

STATUS 


CRT 


COMMAND 

CONTROL 

PANEL 



GO/NO-GO 

STATUS 


CRT 


COMMAND 

CONTROl 


INTERCOM 

PANEL 


KEY- 

BOARD 




INTERCOM 

PANEL 


KEY- 

BOARD 


PANEL 












— 

■ 



TDRS CONSOLE 2 TDRS CONSOLE 3 


GROUND 

CONTROL 

PANEL 

H 

— n 

CRT . 

11 

“ ”3 

CRT 

3 

COMMAND 

13 

- 1 " — 

INTERCOM 

PANEL 

EVENT 

PANEL 


KEY- 

BOARD 

CONTROL 

PANEL 



PROJECT OPERATIONS DIRECTOR 
CONSOLE 



14 


15 

— 

16 

GROUND llL. 

COMMAND 


CRT 


CRT 


CONTROL 

PANEL 

CONTROL 

PANEL 


EVENT 

PANEL 


KEY- 

BOARD 

INTERCOM 

PANEL 


GROUND SYSTEM CONTROLLER 
CONSOLE 


NUMBERS IN UPPER RIGHTHAND CORNER OF CONSOLE PANELS IDENTIFY 

THEIR INTERFACE CONNECTIONS IN CONFIGURATION DIAGRAMS, 

FIGURES 13—1. 13—2, 14-1 AND 15-1. 

\ Figure 12-2. TDRSS Operations Control Center Layout 
















12-12 


STATION EQUIPMENT AREA 



GROUND SYSTEM 
GO/NO-GO 
PANEL 


CRT 

19 

' 

1 

OSCILLO- 

SCOPES 

20 

INTERCOM 

PANEL 

KEY- 
, BOARD 

TTY 



21 


22 


23 

GROUND SYSTEM 
GO/NO-GO 
PANEL 


CRT 


OSCILLO- 

SCOPES 


INTERCOM 

PANEL 

KEY- 

BOARD 

1 

TTY 


Figure 12-3. Ground Systems Consoles 

t 





12.3 CONFIGURATION I: DEC PDP 11 SERIES MINICOMPUTERS 


The OCC functions are incorporated into the baseline DHMS by modifying the 
Control System (Unit 20, Figures 2-1 and 4-1) and replacing the PDP 11/40 machines 
in the TDRS and Orderwire Downlink System (Unit 80) with PDP 11/45 computers. A 
diagram of the CCS is shown in Figure 13-1. 

Four PDP 11/45 computers are used in the CCS as were used in Unit 20. How- 
ever, their power has been increased beyond those in the unmodified Control System. • 
This increase is effected by using solid state (bipolar and metal oxide semiconductor 
(MOS) 16K words) memories, increasing the size of the magnetic core memories (from 
28 to 48K words), and adding floating-point arithmetic hardware. Further, a disk con- 
troller and 2 disk packs (20M words each) have been used for each of the four computers, 
Ollier small peripheral items shown attached to the computers (i. e. , bootstrap circuit, 
clock, etc. ) in Figure 4-1 are included for the CCS computers but not shown in Figure 
13-1. Some organization simplification in the. peripheral sets and switching was made. 
Basically, additional interfaces to control consoles, data storage, and printers were 
added to the baseline equipment and arranged in five Unibus sets rather than eight sets 
as before. 

The CCS now drives and services seven operator and maintenance consoles, an 

increase of four units over those in the baseline system. Functions of the four CCS 
computers are: 

• TDRSS Command and Control 

• TDRS Telemetry Data Processing 

e CCS and GS Monitoring 

® Off/ On Line Backup and Special Data Processing. 

Paragraph 12,2 described the additional software routines that are added to the base- 
line routines to run in these computers. As in the DHMS, the MDHMS CCS also does 
not have single points of failure. Greater detail is provided for the PDP 11 computer 
series Configuration I in Section 13. 
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Only delta costing was performed for the PDP 11 series Configuration I. The 
hardware cost is $400K that includes a 10 percent price increase made by the manu- 
facturer during the time the Phase H study was performed. The implementation cost 
is 90 percent of the hardware cost - $360K. Therefore, the price increase for the 
baseline MDHMS over the baseline DHMS is $1,360. OK [$600K + $400K + $360K = 

$1,360. OK]. This price can be compared to that of a remotely located TDRSS OCC to 
determine the cost benefit in separate or collocated MDHS and OCC capabilities. 

Because of the 10 percent price charge, the baseline DHMS costs provided in 
Section 2 must be increased to $8,249.4K 1 from $7,927.0K 1 . Therefore, the total 
estimated cost for the MDHMS Configuration I with PDP 11 computers, is $9,609.4K. 

Of the total cost, $2,264.6K is associated with the computer hardware (includes 
peripherals, interface circuits, etc.), data storage equipment, and operator and main- 
tenance consoles. This composite (computer, storage, consoles) hardware cost will 
be compared for the different configurations. 

12.4 CONFIGURATION I: VARIAN DATA MACHINE 73 MINICOMPUTERS 

Varian 73 minicomputers were configured similarly to the DEC'S machines for 
Configuration I to obtain a cost comparison for the MDHMS. Operation of the system 
_is -the same as for the DEC computers so the description is not repeated. A diagram 
of the Varian configured system is shown in Figure 13-2. 

Fewer Varian computers are used than DEC computers because: (1) bus control 
computers are not needed (a PDP 11/05 is used with each PDP 11/45 computer in the 
MDR/ Shuttle Downlink System), and (2) one Varian 73 controls two AGIPA channels 
rather than using one PDP 11/05 for each channel control. (Characteristics of the 
computer systems considered during the study may be reviewed in Appendix C.) 

A mic reprogrammable control memory in the Varian machines is considered an 
asset because particular data handling routines, for example LDR frame synchroniza- 
tion, can be microprogrammed to decrease the computer execution time required over 

1 Includes the AGIPA modification for 30-channel phase and amplitude control. 
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that of a conventional control memory computer. Also, the microprogram capability 
provides for emulation of other machines (conventional memory and processor designs) 
so that possible future GS system modifications could be somewhat more easily per- 
formed than with DEC computers. 

The composite hardware (computer, storage, consoles) cost using Varian 73 
computers is $2,184.K. Further description of the Varian computer configuration is 
provided in Section 13. 

12.5 CONFIGURATION II: SEL SYSTEMS 86 MIDICOMPUTERS 

Although the MDHMS functions can be adequately performed with minicomputers 
it is valuable to consider the cost and design of a system configured with midicomputers 
For this report a midicomputer is defined to have a 32 -bit computer word and cost less 
than $300K for a mainframe containing 16K words of magnetic core memory. 

Configuration II is an all midicomputer system using three SEL SYSTEMS 86 
machines. Figure 14-1 shows the system layout. Single point failures do not occur, 
but a finite recovery time is required if one of the two prime machines should fail* 
Because half of the users’ data would be handled by one prime computer, a failure 
would be noticed by possibly 10 users simultaneously. This is not considered a serious 
problem, but in the Configuration I systems, a single minicomputer failure would only 
interrupt data to one or two users before the system would effect recovery. 

There are significant advantages in using the midicomputer rather than mini- 
computers. 

e Ease of concentrating and switching several LDR users data streams for 
input to the disk storage system and NASCOM links 

$ Fewer computers to interconnect in the MDHMS 

e Increased computation power for scheduling and attitude determination 
programs 
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o Lower software development risk 

© Less implementation cost percentage. 

In the baseline DHMS LDR user data pass through switches to the NASCOM com- 
munications channels. Each AGIPA LDR data stream was redundantly interfaced to a 
minicomputer that in turn enabled the data to be recorded on the magnetic disk system. 
For the midicomputer MDHMS, the LDR data are concentrated on input to the computer 
in one computer memory bank. Data are then software directed to the disk storage 
system or to computer interface circuits with the NASCOM channels. In either event, 
software can control the data output to redundant storage elements or communications 
channels without hardware switching operations. 

Because only two or three midicomputers must work together, it is simpler (in 
both hardware and software) to interconnect them than the 23 to 40 minicomputers 
performing the data handling and control operations. Further, the cost of computer 
interconnection and peripheral switching hardware is reduced because less equipment 
is required. 

The midicomputers have 64K words of core memory (includes shared memory) 
and 32 -bit words for mainframe programs and data buffers. In effect this is a sub- 
stantial increase in power over the 16-bit word minicomputers. Fewer instructions 
are generally required to execute a program operation, and less read-in, read-out of 
memory to and from disk program storage is required with the larger machines. Less 
computer program development risk will be experienced if midicomputers are used 
than by using smaller machines; i. e. , it will be easier to get the basic MDHMS soft- 
ware to work properly. There is no reduction in programming cost for the midi- 
computer system, however, because more time will be required to system test the 
composite MDHMS software than would be required to test the smaller midicomputer 
systems packages. 

Perhaps the most significant advantage of the midicomputer system over the 
minicomputer systems is that system costs for computer, storage, and console 
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hardware includes manufacture, integration, documenting, and hardware/ software 
testing by the computer builder. The MDHMS contractor therefore needs to be con- 
cerned only with connecting the composite system to the remaining interfaces and 
performing the applications software programming. For the minicomputer system the 
computer interconnection, peripheral interface engineering etc. , must be performed 
by the MDHMS implementor. 

Because of simplifications the implementation overhead of 90 percent is reduced 
to 70 percent for the composite hardware as a result of decreasing the installation, 
integration, and system test percentage to 20 percent from 35 percent and the system 
documentation percentage to 20 percent from 25 percent. (The previously used imple- 
mentation percentages are described in Paragraph 2. 5.) Note that this percentage 
decrease does not apply to the remaining MDHMS hardware (AGIPA circuits, com- 
mand buffers, etc. ). 

The preceding midicomputer advantages were considered a reasonable justifica- 
tion to examine other than minicomputers for the MDHMS. Configuration II uses three 
midicomputers with some specially designed interface hardware processors (interface 
cards) rather than the several minicomputers used in Configuration I. Interface pro- . 
cessors are designed to frame synchronize the LDR and MDR user data streams, for 
example, where these processors replace the more conventional frame synchronizers 
or synchronization action effected through programmed minicomputers. 

Forward and return links and the NASCOM channels interface with the SYSTEMS 
86 computers through the interface synchronization cards to multiplex direct memory 
channels that in turn are connected to a multiport, multibank core memory. The multi- 
plexer channels are directed by channel control words (CCW) and automatically chain 
the CCW together so the computer only services an established data channel at message 
or storage block intervals. This requires several microseconds at each filled message 
or block interrupt interval. Each memory bank within the core memory has an independ 
ent access from the other banks. Therefore, data I/O cycle stealing is not performed 
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(i, e. , the I/O operations and computer programs are executed simultaneously in 
separate banks, requiring memory cycle delays only when the program must access 
an item of data from a high activity bank). Occasional cycle delays would be experi- 
enced by the directing program when inserting NASCOM message headers and ST AD AC 
type information for the GS to user data messages. 

Separate memory banks are required for the MDR, LDR, OCC telemetry process- 
ing, main operating systems, AGIPA service, and the incoming and outgoing user 
command and ground station control programs. The banks are both dedicated to one of 
the two operational (prime) computers and also shared by the three computers as shown 
in Figure 14-1. 

Half of the user data retuni links would be handled by each of the two prime 
machines. The third computer is an on-line backup and is used for program develop- 
ment, modification, or special data testing or processing. Should a prime computer 
fail, the backup machine would replace its functions. During the replacement activity 
the operational prime machine would handle as much of the failed machine load as 
possible, but a noticeable break in several users' data streams would occur during the 
recovery operations. 

A cursory loading analysis for Configuration II indicated prime computer utiliza- 
tion above 50 percent, which was believed too high because loading a real-time processor 
heavily increases the response time for handling interrupt activities and tends to in- 
crease the software cost. [Less than 50 percent utilization was an arbitrary study 
constraint because machine utilization much above 50 percent (say 75 percent) can in- 
crease software costs by 50 to 80 percent due to the programming effort required to get 
everything working correctly (interrupt routines providing proper service within a time 
constraint, super programmers required to save a few core locations, etc. )}. There- 
fore, we have a certain benign unused hardware factor, but the current computer hard- 
ware cost is about equal to the software cost. Decreasing the hardware cost by 25 
percent could very well add 50 percent to the programming (software) costs producing .... 
a net MDHMS cost increase. Note that the machine utilization factor lead to Configuration 
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Ill where the midicomputers are augmented with controlled minicomputers or data 
processors which handle trivial activities but unload the midicomputers* 

The cost of SEL computers, storage, and console hardware is estimated at 
$2, 215. 5K, slightly less than the DEC equipment cost estimate. Even though each 
midicomputer costs more than a minicomputer, only three midicomputers with inter- 
face connections are required as opposed to several minicomputers and interface 
circuits required in the DEC system. 

12,6 CONFIGURATION IH: XEROX MIDI AND MINICOMPUTERS 

Configuration III was developed to overcome the Configuration II computer utiliza- 
tion excess. Two Sigma 9 midicomputers, one Xerox 530 minicomputer, and 37 Sys 
tern Control Units (SCUs), representing miniprocessors, are used in the design shown 
in Figure 15-1. 

The midicomputers provide the system and data management and OCC data 
processing power. Only one computer is required to run the system, and the other 
machine is an off- or on-line backup that can be used for software maintenance, special 
processing activities, etc* Roth computers have multiport core memories and access 
to shared memory for computer intercommunication. Return link user data are not 
put through the midicomputers normally, only when temporary data storage is required. 

The Xerox 530 minicomputer monitors the midicomputer activity and can be used 
as a data simulator or simulator driver during MDR and LDR return link checkout. 

The SCUs are mic reprogrammable processors that interface to and are controlled by 
the Sigma 9 s. Twenty -four SCUs operate the AGIPA channels, synchronizing the LDR 
telemetry data, and output NAS COM messages to the communication channels. Here*, 
operation is the same as for the PDP 11/05 used in AGIPA channel control. Other 
SCUs handle the MDR user data, concentrate the LDR data streams for input to the 
midicomputer during recording, and preprocess the TDRS housekeeping data prior to 
entering it into the midicomputers. 
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Configuration III system availability is high because a computer or processor 
failure would only momentarily affect one user data stream before another system 
unit would pick up the failed unit load. However, the hardware system is overqualified 
because one SCU could handle two or three AGIPA channels. Reducing the number of 
SCUs would reduce the system cost, which is currently greater than the cost of other 
configurations. Another tradeoff is to consider other manufacturers’ miniprocessors 
for the MDHMS. 

Currently the Xerox computer, storage, and console hardware cost is estimated 
at $3,425. IK, considerably greater than the estimated costs of other systems. How- 
ever, pricing changes expected to be announced during August or September could 
reduce the current cost estimate to a value more competitive with the other configu- 
rations. 

12. 7 CONFIGURATION COMPARISONS AND CONCLUSIONS 

Preceding paragraphs have introduced the three composite system configurations 
conceptually developed and priced during the Phase II DHMS study. The following 
paragraphs compare the MDHMS designs and present our conclusions resulting from 
the study effort. 

Table 12-1 shows the purpose of the computers used in the three configurations. 
All designs were based on eliminating single points of system failure by including re- 
dundant or modular equipment. Further should equipment fail, the systems degrade 
somewhat gracefully in that critical functions are doubly backed up except for Configu- 
ration in (only two control computers are used). 

All systems are automated to the extent that operators or maintenance personnel 

, 1 

only monitor the system displays when all of the equipment is functioning normally. 
Thus they may perform system tests, analyses, maintenance activities, and service 
user requests without, fear of the system operation failing because they did not 
activate a switch or read a meter at some critical time. 
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Table 12-1. Prime and Backup Compute rs Used in MDHMS Configurations 



Configuration 


I 

I 

II 

u. 

MDHMS Computer Functions 

PDP 

PDP 

Varian 

SYSTEMS 

Sigma 

Xerox 

Xerox 


11/45 

11/05 

73 

86 

a 


530 

5CU 


P 

B 

P 

B 

P 

• B 

P 

B 

lJL 

B 

P 

— 

B 


B 

1. Control Computers 









1 
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Control and Command 

1 

3,4 



1 

3,4 

1,2 

2,3 

B 
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TDRS Telemetry Data Processor 

2 

3,4 



2 

3,4 

1,2 

2,3 

1 

2 





Monitor 

3 

4 



3 

4 

2 

3 



1 

N 



Special Process and Backup 

4 

N 



4 

N 

3 

N 

2 

N 





2, TDRS Return Data Handling 

5 

6 



5 

6 

1,2 

3 





1 

2 

3. MDR Return Data Handling 

7,8,9 

10,11 

1,2,3 

4,5 

7,8,9 

10,11 

1,2 

3 





3 

11 

4. LDR Return <AGIPA) 



G —* 

, 

- 29 

12 -h 

- 23 

1,2 

3 
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P - Prime Computer 
B - Backup Computer 
N - None 
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Sufficient computer power is available within the MDHMS to eliminate any real- 
Ume need for the GSFC large scale computers. Except for Configuration II there 
probably is more computer hardware in the GS systems than would be specified after 
a detailed loading analysis of the computer systems was performed. There are two 
reasons for the possible excess. Detailed specifications for the MDHMS have not been 
generated so an additional computer or greater core capacity was included to ensure 
sufficient capacity. A further reason is that programming can be somewhat inefficient 
and still work satisfactorily in the systems. Attempts to optimize the machine utiliza- 
tion in real-time systems is expensive and could cost several times the potential hard- 
ware cost savings. Therefore, we have some benign waste of computer power. 

Not all necessary software has been included in the MDHMS, Precision TDRS 
orbit and attitude determination programs must be run on the GSFC computers. These 
machines are also required to run the TDRS position and attitude maneuver programs. 
The reasons for not performing tills software work at the GS are (1) the GSFC programs 
have been developed for other satellite projects on the large scale machines and it 
would cost less to modify the programs to operate at the GSFC than attempt to rewrite 
them for the MDHMS computers, (2) the programs are not required to operate in real 
time, and (3) the load on the GSFC machines would be increased within acceptable 
limits. 

If the MDHMS uses midicomputers, the orbit and attitude programs could be 
modified to operate at the GS after the system is firmly established, with the possible 
advantage that all TDRSS operations could be performed at the GS. Also the cost for 
the software would not be included in the initial GS development cost. All the informa- 
tion then required from the GSFC is the list of spacecraft to be supported, spacecraft, 
orbit data, and the TDRSS tracking data from STDN stations, 

Some assessments and descriptors of the configurations are summarized in Table 
12-2, Comparing the configurations provides insight into the advantages and disadvan- 
tages of the systems. Functional simplicity defines a degree of MDHMS equipment 
fa&ctionai separation within the configurations, which all use two to six computers in 
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Table 12-2. Configuration Comparisons 


MDHMS Descriptors ' 

Configurations 

I (DEC) 

I (Varian) 

11 (SEL) 

III (Xerox) 


Functional simplicity (Relative) 

Medium 

Medium 

Low 

Medium 

Reliability /availability (Relative) 

High 

High 

Medium 

High 

Hardware risk (Relative) 

High 

High 

Medium 

Low 

Software risk (Relative) 

High 

High 

Medium 

Low 

Software cost (Estimated) 

$2,400. K 

$2,400. K 

$2,400. K 

$2,400. K 

Computer, data storage, console hardware cost (Estimated) 

$2,264. K 

$2,184. K 

$2,215. K 

$3,426. K 

Other hardware and implementation costs (Estimated) 

$4, 946. K 

$4, 873. K 

$4, 287. K 

$5, 305. K 

Total MDHMS cost (Estimated) 

$9,610. K 

$9,457. K 

$8, 902. K 

$11, 131. K 

Computers in configuration (Number) 

40 

23 

3 

40 

Types of computers used* (Number) 

2 (A) 

1 (A) 

1 (B) 

3 (A, B, C) 


*Types: A - Minicomputer 
B - Midicomputer 
1 C - Special Processor 






controlling', scheduling, monitoring, and operating the TDRSS. This is a multiprocess- 
ing, multiprogramming environment. Each function shares the use of the computer 
assets. 

At best, Configurations I and III have moderate functional independence. Because 
the minicomputers perform fewer functions within a given machine, their configurations 
are a little simpler than Configuration III, but this aspect is diminished because six 
machines must work together. Because all functions (control and user data handling) 
are performed in the few Configuration II machines, this configuration is the most com- 
plex, Ideally one would perform only one or two functions per machine, but this would 
be prohibitively expensive. (Note that the assessments are made for the configurations, 
not the computers. The Configuration II machines could be used in Configuration III, 
and vice versa.) 

Reliability and availability are significant MDHMS descriptors because of the 
large number of spacecraft to be supported by the TDRSS and the single TDRS OCC 
location. Minicomputer systems are rated high on availability because of the computer 
multiple redundancy whereby all critical forward link processes can be backed up two- 
fold, Also multiple simultaneous computer failures (a very improbable event) could 
be overcome by physically moving and connecting a similar machine to replace the 
computers that were performing critical functions. Less machine backup is available 
for the midicomputer systems, Configurations n and III, But the larger machine 
configurations are at least singularly redundant in the performance of all critical func- 
tions. 

The hardware risk assessment favors the midicomputer systems. It is felt that 
fewer hardware interfacing problems would occur because of the fewer machines to 
interface and because the computer manufacturer would have to overcome intersystem 
problems prior to system delivery, Configuration II is rated as medium risk because 
some complex interface processors (telemetry frame synchronization cards, etc, ) 
would be developed for the system. 
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Software development is a significant area because of the possible cost increase. 
Multiple independent computers and interfaces and programming constraints and con- 
siderations that must be observed assign minicomputer systems a high risk. The 
midicomputer systems are considered as better risks. Configuration II is not as good 
as Configuration III because of the multiple interrupt processes that the Configuration 
II machines must handle. 

Although software risk factors are different, the estimated software costs for 
all MDHMS configurations are the same - $2.4M - considered sufficient for the initial 
programming to get the TDRSS operational. The risk factors show that there is a 
greater chance that Configuration I software costs would be increased rather than the 
midicomputer program costs. It is expected that software maintenance and modifica- 
tions will add an annual programming cost for the operating TDRSS, which would de- 
crease as the software bugs were removed and as the operations personnel and users 
become satisfied with the service and operational MDHMS characteristics. 

The next level in Table 12-2 compares computer, data storage, and console hard- 
ware costs for the different configurations and manufacturers’ equipment. All equip- 
ment producers are considered to be established computer designers and manufacturers 
and to fabricate acceptable commercial quality hardware. The cost differences between 
Ithe DEC and Varian hardware prices for Configuration I indicate that possible savings 
can be obtained by considering other manufacturers’ minicomputers equivalent to the 
DEC and Varian systems. The relative cost agreement, however, verifies the approxi- 
mate cost estimate of the hardware subset that can be considered reasonable for a fully 
implemented MDHMS. Of course all prices are subject to change because of competition 
and demand. 

Configuration II midicomputer, storage, and console hardware prices are about 
the same as the Configuration I costs, but the Configuration II systems loading is too 
high. Thus, additional processing power would have to be added to have an acceptable 
system. Considering this and the current Configuration III costs, we conclude that 
midicomputer hardware will cost more than minicomputer hardware. However, the 
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estimated lower midieomputer implementation percentage (70 percent versus 90 
percent for minicomputer systems) could offset all or part of the increased larger 
machine costs. 

A significant MDHMS implementor advantage and the reason for assessing the 
midicomputer hardware risk as better than the small machine risk, is that the larger 
computer manufacturer’s integrate the basic computer and peripherial equipment. 

They know their equipment better and are better equipped to integrate disk units, etc. , 
during the building of the computers. Another reason for the reduced midicomputer 
hardware risk is the higher transfer rates (I/O rates) of midicomputers over mini- 
computers. This fact can significantly simplify the disk/computer interface for the 
size of disks required in the MDHMS. Multiport midicomputer core memories (com- 
pared to single or two -port minicomputer memories) more readily support the MDHMS 
operations than composite sets of smaller computer systems. The estimated total s 
implemented MDHMS costs include all hardware, implementation, and software costs. 
A cost of about $9.4M to $9.8M appears reasonable for the fully configured MDHMS. 

Because all systems have modular hardware elements, less than a fully con- 
figured system could be initially installed, and the system could be completed as the 
TDRSS service demand increased, which would allow for a lower TDRSS first cost. 

The number of the computers in the configurations and the loading problem of Configu- 
ration II indicate that a practical MDHMS will have approximately 20 to 40 computers 
and special processors of up to three types. At least two types appear desirable - 
midicomputers and minicomputers. 

The preceding configuration comparisons would not have been possible if only one 
configuration or computer type had been studied. Other configurations are possible 
and many other computer manufacturers’ equipment could have been costed. However, 
additional studies are not warranted until specific MDHMS requirements detail the 
TDRSs that will be used and their characteristics, and until the NASCOM MDHMS-to- 
GSFC communication links are defined in detail. / 
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As an aid in the specifications development, we present the following conclusions 
reached as a result of the study effort: 

© Minicomputer systems are adequate and cost effective for the DHMS. 

© Midicomputers and minicomputers (or controllable processors) are re- 
quired for a cost-effective least risk MDHMS development. 

© Function simplication of the MDHMS can be effected if the OCC scheduling 
and configuration control functions are performed by the DHMS. This 
would permit a minicomputer OCC and a midicomputer/ minicomputer DHMS. 

© An AGIPA channel should have a small minicomputer^ or microprocessor 
to perform the channel phase and amplitude control that is built into the 

AGIPA signal processing circuitry. It should have a read-only memory 

\ 

(ROM) for control and a read/write memory for LDR data, control vari- 
ables, and monitoring data. 

© LDR data can be frame synchronized in a computer interface card costing 

2 

about $3. K in quantities of 30, and operating at data rates up to 100 kbps. 

Although certain other conclusions were drawn, they pertain to specific DHMS and 
MDHMS structures, and those provided are significant in that we can recommend two 
MDHMS concepts based on possible operational responsibility separations within the GS. 

Assuming first that one operational organization is responsible for all GS and 
TDRS operations, we recommend a three midicomputer controlled MDHMS directing a 
configuration similar to Configuration II where each AGIPA channel is controlled by a 
separate minicomputer or process controller, the LDR user data are frame synchronized 
by midicomputer interface cards, and a separate frame synchronizer and minicomputer 
are used for each MDR user channel. 


This would be smaller than the units considered in the study, such as the ’’Naked 
Mini, M a Computer Automation, Inc. product, etc. 

2 

From SEL pricing. 
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The second assumption is that one organization is responsible for the antenna, 
HF/IF, and simplified OCC operations, and that another organization is responsible 
for monitoring, scheduling, configuration commanding, and operating the user forward 
and return link communications and data handling services. In this case we recommend 
splitting the MDHMS functionally where the TDRS OCC functions are performed with 
four minicomputer systems; and a two midicomputer directed DHMS performs the 
scheduling functions (removed from the OCC operations), etc., where the LDR and 
MDR return links are handled the same way as for the one organization operated 
MDHMS. 



SECTION 13 ~ MINICOMPUTER MDHMS CONFIGURATIONS 


13.1 GENERAL 

Operation of the TDRSS is directed and controlled by the baseline MDHMS 
Composite Control System (CCS), which is a direct modification of Unit 20 (Section 4). 

This section provides a description of the CCS for Configuration I that was conceptually 
developed using DEC manufactured PDP 11 minicomputers. Also presented is a Con- 
figuration I discussion where Varian produced minicomputers replace the DEC equip- 
ment. 

13.2 DEC EQUIPPED CCS 
13.2.1 Operations 

The CCS diagram is shown in Figure 13-1. Interface connections are simplified 
with respect to Figures 2-1 or 4-1; however, the same circuits and communication 
interfaces exist. 

Where detailed operational schedule and command information from the OCC would 
have been received by the DBMS, this information is now generated by the CCS, However, 
the Network OCC (NOCC) must inform the MDHMS of the spacecraft (S/C) to be supported 
by the TDRSS, the S/C orbit information or ephemeris, and the kinds and amount of 
support required. In turn, the CCS will generate a detailed GS and TDRS schedule of 
time phased operations and the commands necessary to effect the schedule. 

Two time schedules would be maintained. One schedule would handle operations 
for the next 2-hour period, and a longer period schedule for the next 24 hours would be 
maintained. Both schedules would be updated hourly. The shorter time schedule 
would direct the TDRSS operations if not manually overridden by the MDHMS operators. 
Data in the longer time schedule would be moved to the shorter schedule at the update 
times. 


13-1 




REPRODUCIBILITY OP THE 
ORIGINAL PAGE IS POOR 


|OIiX)UT 

















13-2 
























































The scheduled maintenance philosophy is simple, capable of implementation, 
and we recommended it. Basically there is a time "work buffer" so that the detailed 
command generations are carried out before the commands are used to direct the 
system. For example, a support change to be effected 2 hours after the time the 
change was received would not impose a computation load on the MDHMS direction 
with respect to the next 2 hours because the detailed commands would have already 
been generated. Therefore, 2 hours of computer time would be available to generate 
commands for the period 2 to 4 hours hence. Further, should NOCC directed support 
not have been changed for the period 8 to 48 hours in advance of the current time, 
then the MDHMS would be working on the schedule commands for the period 24 to 25 
hours advanced. 

Information from the NOCC would be received per the command and verification 
links from the GSFC. Response to the NOCC from the MDHMS would be supplied on a 
new communications link (not used in the baseline DHMS), which would also be used 
to supply the GSFC TDRS orbit and attitude programs with some TDRS telemetry data. 
The data would be used in the orbit and attitude and maneuver programs, and they 
would be stripped from the composite TDRS housekeeping data links. During TDRS 
transfer orbit operations, the TDRSS OCC would also supply TDRS commands to the 
GSFC through the new link for distribution via the STDN to the TDRSs. 

Section 4 and Paragraph 12.2 describe other operational details that are not 
repeated here. Operator control of the TDRSS is effected through seven consoles 
driven by the CCS. These consoles were shown in Figures 12-2 and 12.3. 

13.2.2 Hardware 

The operator consoles are connected to the CCS shown in Figure 13-1, Each 
console has three or four panels that are numbered. Their interfaces are indicated 
in the Configuration I composite control system diagram. Fewer Unibus peripheral 
switches are used than before to simplify some of the CCS recovery software and 
operations. 
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Five peripheral Unibus systems are used, of which two are required to support 
the MDHMS operations. These are the command and control and telemetry data pro- 
cessing systems, and each is backed with a redundant system (four systems). The 
fifth system is used to support program maintenance activities and special data pro- 
cessing. The offline and data processing Unibus system is not backed up because its 
operation is not essential to the TDRSS online activities. 

13.3 V ARLAN EQUIPPED CONFIGURATION I 

The Varian Data Machine Configuration I (Figure 13-2) uses twenty-three Varian 
73 computers, arranged in four major groupings. The first group of four computers 
is used for command and control, for TDRS telemetry processing, for system monitor- 
ing, and for offline backup and special data processing. Each computer has 64K words 
of core memory, 512 words of writable control storage, a memory management sys- 
tem, floating-point hardware, direct memory access (DMA), priority memory access 
(PMA), a priority interrupt module (PIM), a disk storage of 14. 5M words, an ASR 35 
teletype, a 300-card-per-minute card reader, and a 600-line -per-minute line printer. 

1 1 

The monitor system controls the Console Status Panels, Numbers 18 and 21, 

and the CRT display and keyboard of panel 22. The offline system directly controls 

the CRT display and keyboard, panel 17 and the ASR 35 teletype of panel 20. Addi- 
tionally connected to the offline system is a magnetic tape controller with three tape 
drives (800 bpi and 75 ips). 

Any two computers can handle the requirements of the MDHMS control with no 
real-time support degradation. The remaining peripherals ai*e controlled via special 
peripheral bus switches, configured so no one failure can degrade the real-time 

i 

operating system. 


The panel numbers are shown in Figures 12-2 and 12-3, 
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The eight peripheral bus switches control the MDHMS I/O equipment. Peripheral 
Bus Swatches (PBS) 1 and 2 are redundant and control redundant equipment to give the 
required backup capability. The following equipment is interconnected with PBSs: 

PBS No, 1 and No. 2 

© Uplink command and command verification links 

• Test simulator 

© LDR downlink computers (12 Varian 73 computers) via a multiplexer 
module interface which is connected to a Universal Asynchronous 
Serial Controller 

© The last three MDR computers are controlled by the same multiplexer 

© The first and second MDR computers are directly connected at the 
output of the peripheral switches via a Universal Asynchronous Serial 
Controller 

• Relay controls for the MDR and LDR user matrix switches 

• Command and schedule links from GSFC (two 56-kbps simplex data links) 
Switches No, 3 and No, 4 control input and output as indicated below: 

• Output composite status of station via two 2.4-kbps NASCOM links 

© Output attitude determination data via two 2.4-kbps NASCOM links 

0 Peripheral bus switch number 3 also handles 256 analog inputs, 256 
bi-level inputs, and 128 control outputs. 

• Peripheral bus switch number 4 also handles the backup 128 control 
outputs. 

© " Data from each of the TDRS downlink computers. 
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Peripheral bus switch number 5 controls the input/output of the control panels 
3, 6, 9 and 10, the CRT/keyboard panel 11, the teletype of panel 23, and a 
600 lines per minute printer. 

Peripheral bus switch number 6 controls the inputs/outputs of the control panels 
13, 14 and 17, the CRT/keyboard of panel 15, and a magnetic tape controller 
with two drives (800 bpi, 75 ips). 

Peripheral bus switch number 7 controls the CRT/keyboard of panel numbers 2, 

5 and 8, the status panel of panel 1 and 4, and a 600-line s-per-minute printer. 

Peripheral bus switch number 8 controls the CRT/keyboard of panels 12, 16 and 
19, the status panel 7, and a magnetic tape controller with two drives (800 bpi, 

75 ips). > 

To provide intercomputer backup and maintain status and schedule for degraded 
operations, the following intercomputer capabilities are provided. Between the com- 
mand and control computer (Cl) and the monitor computer (C3), a shared 16K word 
core memory is provided. Between the telemetry processor computer (C2) and C3, a 
shared 16K core memory is also provided. Between the offline system (C4) and the 
online systems, computer-to-computer DMA interfaces are provided between Cl and 
C4, between C2 and C4, and between C3 and C4. 

The second group of two computers is used to accept three TDRS housekeeping 
telemetry data streams. These two computers have 32K words of core memory, a 
5 12 -word writable control store area, DMA, and an A SR 35 teletype. The TDRS down- 
link system is designed so each computer can be programmed to accept the inputs from 
one, two, or three TDRS. Data received by each computer are frame synchronized, 
buffered, and output to the online system. Control of each computer is maintained by 
the online system. 

A third group of 12 computers is programmed so every computer accepts the 
inputs from two LDR AGIPA channels and either throughputs them directly to NASCOM 
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on the correct user link via a matrix user switch, or outputs to bulk storage via the 
MDR computers 1 and 2. Each Varian 73 computer is controlled from the online system 
to program its AGIPA channels for particular LDR user data streams. The functions 
performed by each LDR Varian 73 computer are: 

0 Input data from two AGIPA channels 

© Frame synchronize the LDR data from each AGIPA channel, block each 
into NASCOM format, and either output to correct user or output for 
temporary storage 

© Control each of the AGIPA channels 

© Provide status of each channel to the control computers 

Each of these 12 computers is configured with a 16K word core memory, 512 words of 
writable control storage, and DMA/PMA interfaces. 

A fourth group of 5 computers has 4 OK words of memory, memory management, 

512 words of writable control storage, DMA and PMA interface logic. Each computer 
is designed to accept the output of four frame synchronizers with the maximum through- 
put on any one computer being no greater than 2 Mbps. These data are then blocked 
into NASCOM format and either output to the dedicated MDR user link or output to 
disk storage. The system is designed to provide sufficient storage capacity for 3, 7G 
bits of data. Each disk storage unit is switchable between two Varian 73 computers. 

Each MDR Varian 73 computer is controlled by the online system, and a directory of 
data stored is maintained. Data output from the LDR computer for storage are input 
to the MDR 1 and 2 computers. LDR data stored in the MDR system can be retrieved 
for transmission via NASCOM to the proper LDR user upon user request. 

An advantage of the Varian system design is that one computer type is used for 
all TDRS functions. This can provide some system programming savings because the 
basic operating system developed will be used by all computers. The system is designed 
to give a high degree of backup capability. Another advantage of using only one type of 
computer is that fewer spare parts will be required than if more types were used. 
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SECTION 14 - MIDICOMPUTER MDHMS CONFIGURATION 


14.1 GENERAL 

Potential advantages of midicomputers over minicomputers as stated in 
Section 12 justify the consideration of the larger computers for the MDHMS. This 
section provides a discussion of the all-midicomputer system. Configuration II. 

Three SEL SYSTEMS 86 midicomputers are used; two machines share the online 
operational load and a third operates as an offline backup and special data processor. 

During the Phase II study, configurations that employed four SYSTEMS 85 or 
SYSTEM 86 machines were considered, but these configurations were rejected because 
of cost and complexity. For the same reasons, two Configuration III concepts using 
three Sigma 8 or Sigma 9 computers were rejected. 

Because of apparent operational machine utilization greater than 50 percent, 
the current Configuration II system must be augmented by using minicomputer or hard- 
ware processors to reduce the main computer loading. This augmentation would occur 
by providing a separate processor for each AG1PA channel and by using a different 
MDR user data handling concept. The augmented system was not studied, but it 
should be when a complete TDRSS definition is available. The following paragraphs 
describe the current Configuration II operational philosophy and the hardware layout. 

14.2 OPERATIONAL PHILOSOPHY 

The all- midi computer MDHMS Configuration II is shown in Figure 14-1. Two 
online SYSTEMS 86 primary computers operate the system. Each machine shares 
the total organizational, directional, and data handling load. One machine is the 
master and controls the other online computer. 

Should one of the primary computers fail, the remaining online operational 
system would pick up as much of the failed machine load as possible, and concurrently 
notify the MDHMS operators of the problem. The next recovery maneuver would 
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connect the offline computer to perform the failed computer's operation. This 
philosophy provides an element of graceful system degradation. During the recovery 
operation only a minor interruption in the users' data would be experienced because 
the operational computer could handle the total load for a short time. The offline system 
operation would be stopped and the system connected to replace the failed online system. 

Because only one machine is required to perform the critical MDHMS functions 
there is double redundancy built into the configuration. This is similar to the mini- 
computer concepts. However, now data for about half of the users would be interrupted 
if a double failure occurred. This problem could be overcome by offloading the AGIPA 
channel control functions to individual processors and handle MDR users' data through 
minicomputers. With these configuration changes the system would perform similarly 
to either Configuration I or III operations. 

14.3 CONFIGURATION II DESCRIPTION 

Certain midicomputer equipment operations different from minicomputer equip- 
ment operations must be considered to better understand Configuration II. By referring 
to Figure 14-1 we see that the high activity data channels are directly connected to the 
-midicomputer core memories via direct memory multiplexers (DMXs) or with multi- 
plexer input/output processors (MIOPs) that communicate through the computer direct 
^memory input/output system (DMIOS). 

In effect the .DMX and MIOP are computer channel controllers that are directed 
by the central processor unit (CPU) operational programs. The memory areas (buffers) 
within core that are temporarily used to hold MDR or LDR data are defined by the CPU 
program. In turn, the program generates channel control words (CCWs) that are 
stored in the MIOP or DMX. The channel controllers use the words to direct the 
storage or retrieval of data words from memory, performing these operations simul- 
taneously with those of the CPU and other controllers. 

.Additionally, the midicomputer memories are composed of independent memory 
banks (8, 192 32 -bit words each in the case of the SEL computers). Data or program 
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transfers to the banks can also occur simultaneously. Thus the CPU program can 
operate without interference or cycle stealing if it is in one bank and the MDR or LDR 
data are being transferred through separate banks. 

The end result of the channel controllers and separate memory bank capabilities 
is that multiple operations can be overlapped in time (occur simultaneously), or can be 
concurrently executed (occurring during the same time period where only one device, 
channel controller or CPU, uses a given computer asset at any instant in the time period). 
Activity of this nature is exactly what we are accomplishing with systems using multiple 
minicomputers. However, with midicomputers the channel controllers perform more 
restricted operations than minicomputers because minicomputers can be programmed to 
do many different things than the MIOPs and DMXs do. 

The effect of operational concurrency is that of switching a computer asset quickly 
and easily for the use of another system element. Sort of a time division multiplex (TDM) 
operation where the control or organization of the sharing operations are built into the 
midicomputer hardware. 

With the channel controller and memory capabilities in mind, it is seen that the 

midicomputer shares its memory with the controllers through four independent ports to 
four independent memory banks. Also three ports to the common (shared) memory 
interconnect the three computers. 

Peripherial switches (PSs) operated by PS controllers (PSCs) connect the MIOPs 
and Multipurpose Acquisition Control Systems/Acquisition and Control Systems (MACSs) 
to one of the three midicomputers. The MIOPs, DMXs and the MACSs contain interface 
cards that connect them to the external system elements. The MACSs are used in low 
activity channels (low data rates), the MIOPs are used in higher rate data channels, 
and the DMXs connect directly to memory through their own port because they handle 
the highest activity channels. 

One set of conventional peripheral equipment (card readers, line printers, disk 
units, etc. ) is used for each computer. The large capacity data storage disks for MDR 
and LDR data are shared by the three machines. 
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A capability exists to input 10 MDR bit synchronized and data clock accompanied 
data streams into two DMXs. The DMX interface is a frame synchronizer card (hardware 
processor) controlled by the appropiate prime system midicomputer. It only performs 
basic frame synchronization (referred to sometimes as minor frame synchronization) but 
in the same way as conventional frame synchronizer units (i. e. , the Monitor units 
considered for the DHMS). Eight outputs from the DMXs connect to the NASCOM MDR 
links. 

The capability to handle up to 24 LDR input data streams is also included through 
frame synchronizer cards in MIOPs C and D. Signal samples from the AGIPA channel 
units and control to the units are handled through the same MIOP interface. The TDRS 
housekeeping telemetry is handled through the same two MIOPs. Twenty output LDR 
streams to the NASCOM links are also supplied. 

Note that the LDR and MDR output messages may be software switched within the 
memory banks rather than hardware switched to the NASCOM links as was done in the 
baseline DHMS configuration. This is considered as a slight advantage for the midi- 
computer system because hardware switches do not need to be developed. 

Major Configuration II advantages and disadvantages have been presented. Solving 
the computer utilization problem by providing AGIPA controller processors and MDR 
data minicomputer systems would not cause the total Configuration II cost to be increased 
much. Compared to the Configuration III costs, should a decision to use a midicomputer 
MDHMS be made, the Configuration II augmented design appears as the least risk system 
compared to the minicomputer systems and a lower cost system compared to that of 
Configuration III. 



SECTION 15 - MIDI AND MINICOMPUTER MDHMS CONFIGURATION 


15.1 GENERAL 

In this section we describe a MDHMS design employing midicomputers that over- 
comes the computer loading problems of Configuration II. Xerox computers of three 
types are used for Configuration III. Two Sigma 9 midicomputers organize, direct, 
and provide the computational power for the MDHMS. They are monitored by a Xerox 
530 minicomputer, and they direct 37 System Control Units (SCUs) that are similar 
to minicomputers which perform AGIPA channel control, and LDR and MDR data handling 
operations. 

15. 2 CONFIGURATION III DESCRIPTION 

The philosophy used for Configuration III was that no one midicomputer failure 
would degrade the MDHMS operation and that either of the midicomputers would be 
capable of directing the system. Normally the backup Sigma 9 would be used as an 
offline backup and as special data processor. The Xerox 530 minicomputer is used as 
the online monitor system that maintains the status of all computers and a data file of 
commands and station schedules due to be performed. If the prime system fails the 
offline system would be brought online; the required peripherals switched over; the 
station status, schedule, and commands transferred over to the new online system 
from the monitor computer; and control would be given to the new online system. 

Figure 15-1 shows the overall MDHMS layout, and the computer equipment inter- 
connections are presented in detail in Figure 15-2 prepared by Xerox Corporation. 

The LDR downlink system is made up of 24 SCUs; each SCU is designed into an 
AGIPA channel and is controlled by the online Sigma 9 to program its AGIPA channel 
for a particular LDR user data stream. The functions performed by the SCUs are: 

G Input data from AGIPA channel ^ / 

© Frame synchronization of the LDR data and blocking of data into NASCOM 
format 
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Control of the AGIPA channel 


© Output blocked data to special SCU 36 and/or 37 

9 Input LDR data from special SCUs (36, 37) for output to dedicated user 
data link 

The special SCUs (36, 37) would either send data to the control system for 
temporary storage, or output the blocked data back to the dedicated user SCU for 
transmission via NASCOM to the data user. 

The MDR downlink system is designed using nine SCUs, each accepting the 
output of a frame synchronizer unit that can handle data to the 1-Mbps MDR rate. 

These data are then blocked into NASCOM messages and either output to the dedicated 
MDR user link or output to the online Sigma 9 for temporary storage. The system is 
designed to provide sufficient storage capacity for 3.7G bits of data. Each MDR SCU 
channel is controlled by the online Sigma 9, and a directory of data stored in main- 
tained by the control computer. 

The TDRS downlink system is designed with two SCUs set up in parallel, where 
each unit can be programmed to accept the inputs from one, two, or three TDRSs, 

Data received by each SCU are frame synchronized, buffered, and output to the control 
system. Control of each SCU is maintained by the Sigma 9, 

Station inputs and outputs other than throughput user data are handled via multi- 
plexer input/output processors (MIOP) on the Sigma 9 system with the following data 
communication interfaces: 

o Two 5G-kbps command data lines to both Sigma 9 computers via the MIOPs 
4 c Two 2.4-kbps composite status output links 

9 Three 2.4-kbps range and range rate links 

9 One 2-kbps TDRS status data links 

© Two 2.4-kbps selected attitude telemetry data links. 
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Peripheral equipment included in the system for each Sigma 9 is: 

© One ASR 35 teletype 

O One 400- card-per- minute reader 

© Two 600-line-per-minute printers 

© Two 75-ips, 800-bpi magnetic tape drives. 

With the use of peripheral control switches (PCSs), the following equipment can be 
switched to either Sigma 9 system: 

1. Two PCSs each having a disk system (controller plus two 45 M~ byte disk 
drives) can swap the system disk in case of online Sigma 9 system failure. 

2. Two PCSs for the bulk storage of 3. 7G bytes of data. (PCS 1 controls 1.4G 
bytes of storage', and PCS 2 controls 2. 3G bytes of storage.) 

3. One PCS having two 75-ips, 800-bpi magnetic tape drives. 

4. One PCS having 256 analog inputs, 256 digital inputs, and 128 digital control 
outputs. 

5. One PCS having backup capacity for 128 digital control outputs. 

6. Two PCSs for seven command, status, and CRT display systems, where the 
first switch controls connections to four consoles, and the second to three 
consoles. 

The advantages of this configuration are that each Sigma 9 computer can handle 
all the requirements of the TDRSS while the other Sigma 9 can be used for future 
development, special data processing, and as an offline backup, or as an online backup 
during criteria operations. Upon the online midicomputer failing, the offline Sigma 9 

can be switched into operation within approximately 2 minutes. Because user data 

/ 

are not handled through the Sigma 9s, the advantage is that during switchover all down- 
link LDR and MDR data channels continue to transmit data to their respective data 
users. Other advantages are that no one failure will degTade the system, and multiple 
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failures in different parts of the MDHMS would degrade the system gracefully. Because 
the system normally throughputs most data via the SCXJs during normal operations, the 
Sigma 9 is only being utilized about 40 percent. The disadvantage with this configura- 
tion is strictly cost. 


15-6 


SECTION 16 - NEW TECHNOLOGY 


An original baseline DHMS preliminary system design, MDHMS study, and 
costing exercise have been completed. Innovative interconnections of equipments 
were developed to provide a high system availability. However, only currently 
available equipment technology was used. Therefore, after a careful review of the 
study activity it has been determined that specific data for the New Technology section 
are not available. 



APPENDIX A - TDRS DESIGN AND COST BASELINE STUDY - 
RELIABILITY AND AVAILABILITY CONSIDERATIONS 


A, 1 INTRODUCTORY SUMMARY 

In support of the TDRS Ground System conceptual design and cost data base development, 
considerations of the systems availability and reliability performance have been investi- 
gated. The purpose of the investigations is to ensure, through cost and design tradeoff, 
that the TDRS, in addition to meeting data handling performance requirements, is capable 
of providing the users with this performance at an acceptably high percentage of time and 
at an acceptably low frequency of failure or outage. Considerations include the reliability 
and maintainability of equipment, the system's maintenance concept, and the system's 
design configuration including extent and specific application of redundancy. 

The investigative results are applied to the design and cost recommendations by use of 
mathematical models which, through iterative exercise, assist in tradeoff decisions. 

The investigation for availability is presented in terms of applicable definitions, model 
development, example calculations for identified partial configurations of the MDR down- 
link system, and supporting considerations of equipment reliability and repair rate. The 
investigation for reliability is limited at this time to a discussion of definitions, approxi- 
mation model formulae for reliability with repair, and assumptions attendant to use of the 
modeling approach. 

A. 2 AVAILABILITY 


A. 2.1 Definitions 

Availability is the quantitative characteristic describing the degree to which a system or 
subsystem is (or is required to be) in an operable and committable state upon random user 
demand in the user environment. For purposes of this program, it may be computed by 
the following expressions: 

(1) A = MTBF = ^ 

MTBF + MDT mtbf m + x 

(2) A = Up Time 

Up time + Down time 

~ ' ■ \ / 

^ These configurations were considered in the initial study phases and are no longer re- 
presentative of the GS design. 
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Where: 


A 

MTBF 

X 

Uptime 


Availability 

Mean-time-between-failure 

Mean down time during one period of MTBF 

Repair rate 
Failure rate 

Total time that the system is: 

Satisfactorily performing its intended function (operating) within 
specified limits during demand 

Fully able to operate upon demand and either in "alert” (standby 
with full power on) status; or in 


Transition between "alert” and operational status 

Downtime = Total time of system outage (inability to achieve ”up time” status) due to 
equipment induced events initiated during up time and portions of other 
events precluding "up time" status during demand. 


Factors of downtime included: 

Equipment induced outage regardless of cause 
Propagation path anomalies within design specifications 
Inefficient control and command of assets 
Error, including human error, in O/M procedures and aids 
Design change or overhaul to accomplish specified performance. 

Factors of downtime excluded: 

Communication mission exceeds specified design performance 
Communication traffic demand exceeds specified capacity 
Enemy induced environment exceeds specified survivability limits 
Natural phenomena or disaster exceed specified environmental limits 
Product modification or improvement under approved programs 
Propagation path anomalies which exceed design specifications. 



A. 2.2 Model Development 


Availability modeling utilizes probability theory. Availability (A) is a probability (the 
probability that an element of the system is in an operate state). The system’s model 
using the multiplication theory determines the probability (A . that the system 
is in an operate state given the availability of each system function. The model takes 
the product of each function required for system success, as follows: 


A , = A ' x A . . . xA 

system Function 1 Function 2 


Function N 


In the TDRS system, many of the functions utilize redundant identical elements. For 
example, the MDR downlink bit synchronizer function employs 9 bit synchronizers of 
which eight are required for full system operation - or system success. In a general 
sense, the function comprises n units of which r are required. 


For purposes of availability modeling, some system functions are configured for partial 
redundancy through use of on-line active spares on a parallel configuration. In these 
cases, the element availability is distributed by the binomial law, and may be calculated 
by the cumulative binomial density function: 


A 


function 





where: 


A = Availability of a system function as previously defined 

function 


U = 1 - A 

n = Number of elements (or equipments) comprising the function 


r 


Minimum number of elements required for function operation 



Binomial coefficient = nl 

jl 


= Identification of terms in the binomial expression and is equal 
to the exponent of U in each term. 



The following assumptions apply within each function: 


© Each of the equipments is identical. 

© Each equipment is either operating or nonoperating (failed); thus, each 
exists in either of two exhaustive and mutually exclusive states. 

• The probability of observing each state at any time for any equipment is 
equal and constant. 

• The mean failure rate and mean repair rate for each equipment is negligible; 
and constant. 

o Time to detect failure and to switch to a redundant unit is negligible; 
repair is started at the instant of failure. 

© Equipment failures are independent of each other. 

9 Equipment duty cycle is continuous. 

These assumptions are reasonable for TDRS, which although not meeting these assump- 
tions in every detail, is sufficiently in keeping with them to allow reasonable estimates 
of function availability using the binomial model. 

A. 2. 3 Calculations 

A. 2, 3. 1 TDRS Function Area Considered 

For the example calculations, the MDR down link consisting of Switch RF-3, bit synchroni- 
zation and frame synchronization (not including computer interface Switch CS-1) will be used. 
Two configurations will be computed: 

• The first includes switching (MS-1) between bit and frame synchronizer, 

© The second assumes hardwiring between the bit and frame synchronizer. 

Both consider the soft decision bit synchornizer to have an MTBF equal to the hard 
decision bit synchronizer. 
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A. 2, 3. 2 Configuration I (including Switch MS-1) 


RF3 


- 

Series 

(RF-3) 







RF 3 


Bit synch. 
No. 1 


~RTT 

parallel j- 


9 paths 


| Bit synch. 
No. 9 



MS-1 

(series) 



A (configuration 1) = A x A x A x A = ,99999880 where: 

12 3 4 

A^ - . 99999955 (see Paragraph 2.4.1) 

A = .99999974 
z 

A = ,99999955 (see Paragraph 2.4.1) 

3 

A . =* .99999996 

4 

and: 

Path availability A g = A RF _ 3 x synch _ 

= .99999955 x .99991667 (see Paragraph 2.4,2) 

= . 99991622 

A = A 9 + 9A 8 U 
z 

« .99924623 
+.00075351 


FS 

JTo. 


FS 

No. -J 
9 


99999974 








CALCULATION OF A, 

4 

Path availability (^4) = A___ ,, , x A. , 

MS-1 parallel frame synch 

= . 99999955 x . 99996667 (see Paragraph 2.4. 3) 

= .99996622 
9 8 

A . = A +9A U 
4 

=* .99969602 
+. 00030394 
,99999996 


A, 2, 3.3 Configuration II (without Switch MS-1) 




A (configuration 2 ) = A x A - ,99999906 where: 

A^= .99999955 (see Paragraph 2.4, 1) 
A 2 = .99999951 

and 


Path availability (A^) 

, } 


= ^3 parallel * s ^ oh - * Aframe synch. 

— ,99999955 x .99991667 x ,99996667 (see paragraph 2.4) 


« .99988289 
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9 8 

A = A + 9 A U 
2 

= .99894653 
+.00105298 

.99999951 

A, 2. 3. 4 Relationship of Function Outage to Availability 

The following calculations of downtime provide a practical method of presentation of 
changes in availability. These calculations are based on one year of continuous opera- 
tion and assume 8000 demand hours for this purpose: 

A = uptime 

uptime + downtime 

A (uptime) + A(downtime) = uptime [assumed one year's operation (8000 hours)] 
A (downtime) = uptime - A (uptime) 

= uptime (1 - A) 
downtime = uptime (1 - A) 

A 

= 8000 x 60 1 -.99999880 

.99999880 

= 480,000 x .00000120 
= 0. 58 minutes average outage/year 

= 8000 x 60 1 - . 99999906 

. 99 99990 6^ 

= 480,000 x ,00000094 
= 0.45 minutes average outage/year. 
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Comparison of these calculations indicate that, for the example functional configurations, 
deleting Switch MS-1 reduces expected outage from . 58 to . 45 minutes (approximately 8 
seconds) per year. This improvement does not, by itself, provide justification for deleting 
the switch. Tabulations or plots of downtime and cost for different candidate configura- 
tions would be useful for tradeoff purposes. 

A. 2. 4 Equipment Supporting Considerations 
A. 2.4.1 Switches MS-1 and RF-3 

RF-3 Function - Switch any of 9 demodulator outputs to any of 9 bit synchronizers 
MS-1 Function - Switch any of 9 bit synchronizer outputs to any of 9 frame synchronizers 
Assumed Switch Configuration 

Each switch is assumed to be solid state and to consist of 10 segments consisting of 9 
diodes each. The first segment of each switch is a master switch selecting which of the 
bit and frame synchronizers are to be used, and is serial to the total MDR downlink 
system. The remaining 9 segments of each switch perform interconnections between 
units and are serial to their respective elements, but not to the total system. 

6 

For computation purposes, switch segment failure rate is 2.7 failures per 10 hours 
based on 0. 3 failures per 10° hours for a digital Active Element Group (AEG), and 9 
AEGs per segment (Reference 1). This is equivalent to 370,370. 370 hours MTBF . 

Repair by segment replacement within 10 minutes (6 per hour) is assumed for the 
switches. (Provision of standby switch segments with automatic switchover would 
shorten repair downtime to the millisecond downtime region through additional system 
hardware and software.) 

Switch segment availability is calculated as follows: 

A = ** = 6 

ss fi + x 6 + 2.7 x10~6 

— __ 6 

6 + . 0000027 where H ~ repair rate (repairs/hour) 

= .99999955 * = failure rate (failures /hour) 


Reference 1 - RADC Reliability Notebook, November 1968, Vol. 1, pp 9-20, Fig. 9-3. 
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A. 2, 4, 2 Bit Synchronizers 

For the MDR and shuttle down link, the system configuration consists of 9 bit syn- 
chronizers of which 6 are the hard decision type and 3 are the soft decision type. 

During nonshuttle operations, any 8 of the 9 are assumed as required at all times. 

During shuttle operations (exclusive of handover) the requirement is for 7 hard 
decision and one soft decision bit synchronizer. 

Monitor 317 series bit synchronizers are assumed. The manufacturuer predicted MTBF 
is 27,953 for the hard decision bit synchronizer. This value is considered by CSC to be 
optimistic from the reliability standpoint. According to the manufacturer's data, the 
unit contains 921 transistors and diodes, 274 integrated circuits, and several hundred 
other components. CSC estimates the unit complexity at 1200 digital AEGs. Using 
Reference 1 and giving reasonable credit for high -re liability design, CSC assigns an 
MTBF of 2,000 operate hours for this unit, and 500 x 10"® failures /hour. Downtime 
is assumed to be 10 minutes for replacement, or a repair rate of 6 per hour. Based on 
these data, bit synchronizer unit availability is calculated as follows: 

A = M 
M + X 

= 6 

6 + 500 x 10-6 


= 6 

6.0005 

=.99991667 

A. 2. 4, 3 Frame Synchronizers 

For MDR and shuttle down link, the system consists of 9 frame synchronizers and two 
channels for extracting shuttle voice. It is assumed that 8 of 9 frame synchronizers 
and 1 of 2 shuttle voice channels are required at all times. The shuttle voice channels 
are assumed to have the same MTBF as the frame synchronizers. Monitor 430 series 
frame synchronizers are assumed. Manufacturer predicted MTBF for the basic unit, 
including word synchronization, is 21,882 hours. This value is considered by CSC to 
be optimistic from the reliability standpoint. According to the manufacturer^ data, 
the unit contains 100 transistors and diodes, 596 integrated circuits, and over 100 other 
components. CSC estimates the unit complexity at 700 AEGs, and giving reasonable 
credit for high-reliability design, CSC assigns an MTBF of 5000 operate hours for this 
unit, or 200 x 10-6 failures /hour. Downtime is assumed to be 10 minutes for replacement, 
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or a repair rate of 6 per hour. Based on these data, frame synchronizer unit avail- 
ability is calculated as follows: 

A = M 

M + X 

= 6 

6 + 200 x 10”® 

» 6 

6. 002 

= .99996667 
A. 3 RELIABILITY 

v 

A. 3.1 The Systems Reliability Concept 

The worth of any system ultimately depends on its ability to do the job for which it was 
designed when operated in the field environment by the user's personnel. The funda- 
mental goal of systems procurement is to acquire a system of adequate operational 
effectiveness, when needed, and for a total cost of procurement and start up within 
economic limits. Emphasis on performance capability alone (e.g. , data rate and bit 
error rate) does not necessarily result in the required level of effectiveness. Other 
character tistics must be considered. These are indicated in Figure A-l. 



Figure A-l. Pictorial Representation of System Effectiveness Definition 
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The specific, basic analytical model proposed by Test Group n of the Weapon System 
Effectiveness Industry Advisory Committee (WSEIAC) is presented in symbolic form 
by the following expression:* __ __ 

E = A' [D] C 

where 

E “ System Effectiveness, a measure of the extent to which a system maybe expected 
to achieve a set of specific requirements and is a function of availability, depend- 
ability, and capability. 

A = Availability, as previously discussed, is a measure of the system’s condition at 
start up. It is a function of the relationships among hardware, personnel, and 
procedures. It may frequently be expressed as a probability (in terms of mean- 
time -between -failures (MTBF) and mean-time-to-repair (MTTK))that the system 
will be ready upon random demand to operate at a specified level of performance 
capability - a measure of how often the system is ready when needed. 

[D] Dependability is a quantitative measure of the system condition at one or more points 
during operation, given the system condi tion(s) at start up. It may be expressed as 
a probability (reliability) that the system will maintain a specified level of perform- 
ance throughout a given operating period, a measure of how long the system is capable 
of working without failure. 

C Capability is a measure of the ability of a system to meet operating objectives, given 
the system condition(s) during operation, and specifically accounts for the design per- 
formance of a system. It may frequently be expressed as a measure of how well the 
system does its job when working properly. 

Thus, reliability and maintainability, in the context of total system requirements, occupy 
a vital role in the fulfillment of system objectives. 

Fulfillment of system objectives for effectiveness and reliability have been routinely and 
successfully accomplished for many DOD systems through application of system reliability 
engineering principles. Although TDRS presents a number of unique problems, these 
principles are as applicable to the TDRS as they are to the types of DOD systems for 
which they were developed and are normally used. Analysis of reliability, frequently 
expressed in terms of MTBF, will indicate how to improve a system's design by reducing 
the rate of failures which produce outage. 


*CSC, under contract to Rome Air Development Center (RADC), has developed a Sys- 
tems Effectiveness Handbook to implement the concepts proposed by WSEIAC. Re- 
sults of this study are available for CSC support of the TDRS design/cost analysis. 
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A. 3.2 Reliability Definitions 


The reliability of a product is generally defined as the probability that the product will 
give satisfactory performance for a specified period of time when used under specified 
conditions. When applied to a specific equipment or system, reliability is frequently 
defined as: 

• The probability of satisfactory performance for specified time and use 
conditions; or 

• The probability of a successful mission of specified duration under specified 
use conditions; or 

• The probability of a successful [event] under specified conditions, where the 
event may be independent of time. 

Whenever the definition is worded to fit a particular system or device, it is always 
necessary to relate probability to a precise definition of "success" or "satisfactory 
performance", to specify the time base or operating cycles over which such perform- 
ance is to be sustained; and to specify the environmental or use conditions which will 
prevail during this time period. 

As a general rule, applicable to most electronic equipment of conventional design/ a 
simple relationship exists between the reliability of an equipment and its mean life, or 
mean -time-between -failures (MTF or MTBF). This relationship is the "exponential" 
case, which holds when the "failure rate" of the equipment is constant during its ser- 
vice life, shown by the following equation: 

R (for "t" hours) - e ^ UTF 

Because of this relationship, reliability may be expressed in terms of an allowable, 
mean-time-to-failure, MTF, or mean life, 0. 

Failure rate in the above exponential case is the reciprocal of mean life, represented 
by FR or ^ (lambda): 

FR = 1 = 1 = = A 

MTBF MTF 0 


Designs in which redundancy has not been used extensively. 
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A. 3. 3 Model Development and Assumptions 


Reliability modeling for the TDRS requires consideration of reliability with repair 
concepts; that is, when a system consists of n~identical parallel subsystems, each 
having an exponential distribution of times to failure and an exponential distribution 
of times to repair. The system reliability with repair is the probability of no more 
than q out of n subsystems being simultaneously in a failed state during time t. 


Consider a system consisting of n- identical subsystems: 


. Let A “ subsystem failure rate 
u = subsystem repair rate 
n = total number of subsystems 

q = number of simultaneous subsystem failures permitted without 
system failure 


t - operating time 

R(t) = system reliability with repair, i.e. , the probability that no more 

than q subsystems are simultaneously in a failed state being repaired 
during an operating time of length t, given that all subsystems are 
initially operative 

T - mean time for the system to pass for the first time from zero to (q + 1) 
m simultaneous subsystem failures. 


Although the exact calculation of reliability with repair requires the solution of (q + 1) 
simultaneous differential equations, there is a wide range of values of n, q, ^ , and u 
where reliability with repair can be approximated by: 



Approximation formulae developed by McGregor are applicable to TDRS and are 
summarized herein. 


2 

McGregor, ’’Approximation Formulaes for Reliability with Repair, ” IEEE Trans 
actions on Reliability, Volume R-12, Number 4, December, 1963. 
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With single repair capability, only one subsystem at a time can be repaired. Whenever 
subsystem fails, it enters a "failed state” until it is repaired and returned to the "operat- 
ing state". If q subsystems are permitted to be simultaneously in a "failed state", then 
system reliabilit}^ with repair B(t) is the probability that no more than q subsystems are 
simultaneously in a "failed state" during a specified operating time t given that all sub- 
systems are initially operative. By this definition of reliability with repair, the number 
of simultaneously failed subsystems may vary from zero to q, but never exceed q during 
time t. 


For the following conditions frequently met in practice, simplifying approximations may 
be made: 

u > I0n\ 

t > 3 _ 

u 

2 - n 4 100 


Using these assumptions, the following approximation for reliability with single repair 
is developed: 


R(t) - exp 



[(n-q-1): u 


q 


The preceding discussion of reliability with repair of systems having single repair capability 
is applicable, with certain modifications, to systems having multiple repair capability. For 
..multiple repair capability, simultaneous repairs can be performed on q subsystems simul- 
taneously in a failed state. 

The deviation of the equations for multiple repair is similar to the derivation of the equa- 
tions for single repair. For multiple repair, simplifying approximations are available for 
the following conditions: 


u > 5n X 
t >3/u 
3 < n< 100 
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Using the preceding assumptions, the following approximation for reliability with multiple 
repair is developed; 


R(t) = exp 


-nl ^ +1 t 


(n-q-l)l q l u 


The above approximations for 1 re suit, in a pessimistic value of reliability with repair „ 

T 

m 

However, since the TDRS functions generally mil satisfy the assumptions made, the approx- 
imation effort is not expected to significantly degrade utility of these approximations for 
TDRS. It is concluded that either method ^nost likely the multiple repair approximation 
based on the currently considered TDRS maintenance concept of repair -by-replacement) 
may be used, either manually or by computer, to quantify the reliability impact of TDRS 
design alternatives in support of trade-off decisions. 
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APPENDIX B - REVIEW OF TWO ASPECTS OF TDRSS 
B.l INTRODUCTION 

Two aspects of the Tracking and Data Relay Satellite System (TDRSS) Configura- 
fl 2] 

tion L ' * JJ have been reviewed. The two areas include, 1) the implementation of the PN 
code tracking system, and 2) the implementation of the frequency acquisition procedure. 

B. 2 PN CODE TRACKING 

The early -late PN tracking system (also sometimes referred to as a delay-lock 
discriminator) as shown in Ref. [1], pg, 11-8 and Ref. [2], pg. 3-74, seems to be incomplete. 
The input to the code-traeking-loop filter should be formed by first differencing the 
correlator outputs from the two channels. Also, the method is not shown by which the 
phase shift keying, due to the presence of data, is removed from the error signal. 

The concept of the early-late tracking technique is shown in the lower left-hand 
corner of Fig. B-l. Such a scheme correlates the incoming signal (carrier which is phase- 
shift keyed by the PN chips) with carriers which are balance modulated by both an undelayed 
(early channel) and a delayed (late channel) sequence from the reference PN generator. 

The delay is selected 1/4 to 1 PN chip, usually 1/2 chip. The clock that drives the local 
PN reference sequence is advanced or retarded (i. e B , phase shifted) until the incoming 
PN sequence falls midway between the two reference codes. To sense the null condition, 
the outputs of the two correlation channels are subtracted; when tracking perfectly with 
no error, the two outputs should be the same giving zero error signal. 


[1] "Tracking and Data Relay Satellite System Configuration & Tradeoff Study", Vol. V, 
User Impact & Ground Station Design, October 1972, Submitted to Goddard Space 
Flight Center, National Aeronautics & Space Administration, by Space Division 
North American Rockwell, under Contract NAS5-2 1705, Report SD 72-SA-0133-5. 

(2} " ", Vol. Ill, Telecommunications Service System, SD 72-SA-0133-3. 
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When binary PSK data is present on the incoming signal, the PN sequence at 
the input can be considered to be complemented (or inverted) by a data "-1". These 
inversions occur randomly and invert the sense (algebraic sign) of the error signal 
to the code tracking loop. The effect of the random data can be removed in the 
following ways: 

Use a noncoherent code-tracking configuration where in-phase/ quadrature 
channels followed by envelope detectors are used on each of the early-late 
channels, 

2. Utilize a demodulation/remodulation scheme with hard decisions from each 
symbol being used to multiply (±1) the error signal and therefore correct 
its algebraic sign. 

3. Similar to 2), use a decision-di 2 ’eeted feedback scheme with decisions from 
the decoder being fedback to correct the polarity of the error signal (the 
delays involved make this technique impractical). 

Note that 1) works by making the code tracking scheme insensitive to knowledge of 
carrier phase. However, losses are incurred in the envelope detectors. Technique 
2) niay be the best compromise although at low SNR (relatively high symbol error rates) 
—the error signal will be fairly noisy. 

B. 3 FREQUENCY ACQUISITION (See Figure B-2) 

The technique proposed for frequency acquisition is basically sound and should 
work if the SNR is high enough. The key parameter is the signalling energy per 
observation interval (= <$ 0 ) to noise density ratio ($o/N 0 ) which should be in the region of 
12 dB or more for reliable detection. The technique would collect the N complex 

samples Z k - 0 1. 2 . . .. (N-l) and compute the N complex coefficients of the dis- 

k c 

Crete Fourier transform (DFT) 

A r = S Z k exp { - j ¥ kr > 
k=0 

k= 0, 1 (N-l) 

r= 0, 1, .... (N-l) 
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Signal will be + 12 kllz 


Background Noise 


Sampling Rate 


-32,000 


sm (f LO 0 




32,000 

frequency 


Consider a Block of 320 Points 



3 Bit Words 



Treat as Real Samples 




3 Bit Words 


These are actua 


.Treat These as Quadrature 
Samples 


N is Block Length 

@ 100 Bits/Second, T b = 10 * 10~ 3 Seconds. Therefore collect 
320 samples in 10 ms. 

In 10 milliseconds, want to cycle "r" through all values 0 to 319 (or -159 to +160), 
for each r must let k range through 0 to 319. For example, consider r = 2, k * 2 
are doing; 

R ik + ,I *“ pc 2 +JY 2 > exp { M ir* 2,2 } 

= (X 2 + ]Y 2 ) cos(~’ 2*2) -jsin(— -2-2) 

= X 2 cos ( ~~ • 2 • 2) + Y 2 sin ( ~~ • 2 ■ 2) } Real Part of Answer 

+ j Y 2 cos ( - j X 2 sin (~2*2) } Imaginary Part of Answer. 

319 

R I 

Will accumulate reals and imaginary’*? to get A r = A f + j A r i. e. , A r = R rk + ] *rk 

Therefore. 4*320*320 multiplies are required in 10 2 seconds. 


By using Fast Four 
of multiples required to - 


N ~ 256 Points— j 
N = 512 Points — 

For N = 256, Time/MU L 
4. B fi sec/multiply. The- 
words this is well wii 
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aad then compute the discrete power per spectral line as 

P = A A * 
r r r 

A "peak-picking" routine would find the largest spectral line and compare this line 

(say P ) to the sum of all lines, i. e. , the decision rule would be 
max * * 

N-l 

IF (P - ~ V P ) > T 
max N r — 

r=0 

th 

state that signal is present in the max frequency cell a Errors that can occur are 

8 S probability of missing signal when in fact it is present 

a = probability of stating that signal is present when it is not (i. e, , 

the false- alarm probability) 

c = stating that signal is present (when it is) but selecting the wrong cell. 

To implement this technique at complex sampling rates of 10-20k samples/ 
second, the fast Fourier transform algorithm would be used. The threshold (T) 
could be selected to give a fairly high fals e-alarm rate thus giving low values of 

Computer simulations would be required to evaluate the effects of quantization, “ 
unknown signal and noise parameters, and so on. We may speculate that an S o /N q of at 
least 12 dB will be required for satisfactory operation. 
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APPENDIX C - CHARACTERISTICS OF COMPUTER SYSTEMS 
CONSIDERED IN THE DHMS STUDY 


C.I INTRODUCTION 

General characteristics of the computer systems considered in this TDRS ground 
station study are presented. A standardized format provides information on the system 
architecture, peripherals, and software. 

Three minicomputers are discussed: the Varian 73, the PDP 11/45, and the 
Xerox 530, Each should be considered as large minicomputers. They can contain 
several thousand core locations, and they are generally supported by multiprogramming 
software, floating point hardware options, and real-time operating systems. Each has 
16 -bit computer words which is the criterion for their classification as minicomputers. 

A Xerox System Control Unit (SCU) is also discussed. It is similar to a mini- 
computer, but is not classified as such because it is designed to implement one or a 
constrained set of functions that support some operations of a computer system. For 
example, it may be programmed as a disk controller (interfaces disk drives to a 
computer system) or to act as an input data handler for the TDRS, LDR, HDR, and 
housekeeping data streams. 

The SYSTEMS 86 and Sigma 9 computer systems are also surveyed. They 
represent midicomputers, a system between the minicomputer and large scale computers 
(EBM 360/75/95, etc,). The major criteria used for the midicomputer classification 
is a word length greater than 16 bits (24 or 32 bits) and a basic mainframe cost of less 
then $300K (includes the processor unit and at least 64K* of core memory). Each 
system has multiprogramming and multiprocessing capabilities and 32-bit computer 
words. 


K-1024, used as a measure of core size because core usually comes in integer 
increments of 1024 bytes or words. 
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C.2 VARIAN 73 


The Varian 73 is a microprogrammed computer with 64-bit control words 
dictating the flow of data through a 16- register processing section. The computer can 
process all previous Varian 620 programs, and with the addition of a Writable Control 
Store Option, the microprogram can be extended to meet special system requirements. 

C.2.1 Architecture 

The Varian 73 is available with either semiconductor or core memories or with 
any combination of the two. All memories are dual port for interleaving of I/O and 
processor functions. Built-in features allow multiple central processors to share 
memory, simplifying the implementation of a multi-processor system, 

C.2.1.1 Memories 

The computer processes 16-bit words in a full cycle memory time of 330 
nanoseconds (semiconductor memory) and 660 nanoseconds (core memory). The standard 
16-bit word contains 8-bit bytes. An optional 18 -bit word is available to provide a 
parity bit for each byte. 

Core Memory - The core memory system is a two-port, random-access, three- 
wire/three dimensional, magnetic core memory for storing instructions and data. The 
core memory is expandable in increments of 8K modules. Through jumper selection, it 
provides odd/even address interleaving between core memory modules. 

Semiconductor Memory - The semiconductor memory is an expandable, random- 
access, metal oxide semiconductor (MOS), asynchronous system. Each printed circuit 
board can accommodate up to 8K 16-bit words. A battery powered data save option 
may be added to the power supply when semiconductor memory is included in the 
system. 

Dual Ports - Both core and MOS memories are provided with two fully 
implemented ports, each connected to one of two parallel memory buses. This means 
that one memory may be communicating with a processor while another is transferring 
data to or from another processor or an I/O device. 
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Memory Mapping - The Memory Map option performs address relocation and 
memory protection for up to 26 2K memory locations. Any user program may employ 
up to 32K words of memory in 512 word blocks. 

Memory Protect - The memory protect option prevents the programs from 
accessing memory that has been protected by a MASK stored in the option, which can 
be applied, removed, and changed under program control. 

Memory Parity - Another memory option checks the parity of every data transfer , 
on the dual memory bus. Two parity bits are used, one for the 8 most- significant-bits, 
the other for the 8 least- significant-bits. 

C.2. 1,2 Processor 

Data flow is controlled by microinstructions stored in Read Only Memory (ROM). 
Execution time per microinstruction is 165 nanoseconds and the user can add an 
optional Write Control Store (WCS) to create his own microinstruction set. 

Processor Microprogram - The standard Varian 73 microprogram consists of 
512 microinstructions, each a 64-bit word stored in the processor ROM. The 64 bits 
are divided into fields which control the flow and manipulation of data throughout the 
machine, A single microinstruction can dictate a number of different machine functions: 
register, memory and I/O transfers, arithmetic and logical operations, and test on 
the conditions of registers, 

User-Written Microprogram - Special microprograms can be written to adapt the 
Varian 73 to special application requirements. 

Instruction Set - The standard Varian 73 microprogram is designed to decode and 
emulate the instruction set. Multiply/divide operations are performed by standard 
hardware. The 159 standard instructions may be extended with the Write Control 
Store option. 
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Registers - 16 general purpose and 8 special purpose 16— bit registers are 
provided and all are accessible to the microprogram. 

C. 2. 1.3 Interrupts 

The Varian 73 has a true hardware priority interrupt structure, expandable up to 
64 levels, with automatic interrupt identification. External controllers can all request 
interrupts and specify the interrupt location via the address lines of the Varian 73 I/O 
■bus. An optional Priority Interrupt Module (PIM) provides hardware priority arbitration 
and interrupt address (vector) generation for 8 levels. Up to 8 PIMs may be interfaced 
to the I/O bus of a processor. Interrupts may be enabled or disabled individually or in 
groups, 

C.2. 1,4 Input/Output 

The Varian 73 facilitates four different ways to communicate with peripherals and 
other sources. The result is flexibility in selecting the I/O technique that will provide 
j the highest possible data transfer rate at minimum cost in processor time. All data 
transfers, except for Priority Memory Access (PMA) I/O, are over the party-line I/O 
bus, with 16 bidirectional lines for addresses and for data, plus an additional 14 lines 
for timing, sense, and control signals. PMA transfers are direct to memory with 
separate 16- line buses for addresses and data. 

Programmed I/O - Programmed I/O operations are initiated by the central 
processor and are used primarily to control and sense the state of peripherals, to 
prepare controllers for other types of I/O transfers, and to communicate with low- 
speed devices* 

Direct Memory Access (DMA) I/O - Direct data transfers between I/O bus and 
memory are effected in the DMA mode. The technique is implemented by a Buffer 
Interlace Controller (BIC) option that stores the initial and final addresses of the data 
words to be transferred. The transfers are made on a cycle stealing basis. DMA 
transfers can occur at rates up to 333,000 words per second. 
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High-Speed DMA - Special control lines are provided for peripheral controllers 
that are able to operate at "high speed, " DMA rates up to 1 million words per second, 

A similar BIC operation is used to implement transfers at this higher rate. 

Priority Memory Access (PM A) I/O - Data transfers at the full memory cycle rate 
(3, 03 million words per second, in the case of a MOS memory) can be obtained through 
the PMA channel. A PMA controller is loaded with the initial and final addresses of the 
data words to be transferred. Controller data and address lines are connected directly 
to the memory bus. 

C.2. 2 Peripherals 

Each standard peripheral subsystem is an integrated unit, including the device 
itself, interconnecting cables, I/O controller and software for its operation. The 
standard Varian peripherals are supplemented by a list of over 100 other peripheral 
models that may be supplied on special order. A list of the standard peripherals follow: 

Fixed Head Disks 
Moving Head Disks 
Drum Memories 
Magnetic Tape 
Teletypes 

High Speed Paper Tape 
Card Reader 
Card Punch 
Line Printer 
Digital Plotter 
Electrostatic Plotter 
Analog Input Controllers 
Analog Output Controllers 
Digital Input Controllers 
Digital Output Controllers 
CRT Display 
Relay Interfaces 
Data Set Couplers 
Communication Controllers. 
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C.2,3 System Software 

The Varian 73 is fully supported with extensive software. Available are operating 
system software packages, macro-assemblers, compilers, mathematical and data 
conversion packages, and support packages (editing, debugging, and diagnostic programs), 

C.2,3, 1 Operating Systems 

Two software operating systems are available for use with Varian 73 computers: 
VORTEX and MOS. 

VORTEX (Varian Omnitask Real-Time Executive) - A multiprogramming system 
with special features designed for real-time applications. A number of different tasks 
may be stored in the main memory or on a rotating memory device. The tasks are 
scheduled by a resident executive program that gives highest priority to real-time 
foreground programs. Lower priority background programs are executed during 
the idle intervals. 

MOS (Master Operating System) - An integrated batch process software system. 

It conserves main memory space for the user by allowing all software elements, except 
for a small resident monitor, to be stored on the rotating memory or magnetic tape and 
loaded into the computer only when needed, 

C. 2. 3. 2 Assemblers 

Three versions of the Varian Decisions Assembler (DAS) are available. DASMA 
is designed for a minimum system comprising a computer with 4K memory and a 
teletype, DASA8A provides expanded capabilities for system with at least 8K memory 
and an additional peripheral storage device. The third comprehensive assembler 
is DASAMR, an integral part of the VORTEX and MOS operating systems. DASAMR 
is a macro assembler which produces relocatable code and recognizes the macros 
required for VORTEX real-time services. 
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C. 2. 3. 3 Compilers 


The compilers provided for the Varian are as follows: 

FORTRAN IV - An integrated software package that consists of a single pass 
compiler, a relocating loader, and a run-time package, 

BASIC - An advanced version of the self- teaching system developed at Dartmouth 
College, 

Advanced BASIC - Expands the BASIC language to make it a more powerful tool 
for researchers who are operating in "real-time”, 

RPGIV - A business-oriented language for preparing statistical data and tabular 
reports, 

C. 2. 3, 4 Support Packages 

The following support packages are provided for the Varian 73: 

BEST (BASIC Executive Scheduler and Timekeeper) - A real-time monitor that 
automatically schedules core resident programs according to the time of day, at fixed 
time intervals, or at the earliest opportunity. 

BLD II - Used to load object programs from a paper tape or TTY reader 

AID n - An online debugging program 

EDIT - Used to modify symbolic programs 

MAINTAIN II - Checks that all hardware elements are operating correctly 

MATH LIBRARY - A comprehensive set of mathematical function subroutines, 

C. 3 SYSTEMS 86 

The SYSTEMS 86 computer was designed to meet the needs of real-time 
applications. SYSTEMS 86 comes with a four-port memory, ^enabling two 86s to 
process in a shared-memory, multiprocessor configuration and conduct simultaneous 
I/O with both processors. 
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C.3,1 Architecture 


The SYSTEMS 86 major hardware elements include a Direct Memory Input/Output 
System that transfers directly to memory via a separate memory port at 1, 67 million 
transfers per second, up to 128 interrupt levels, modularly expandable memory, and 
a 152 instruction repertoire. 

C. 3. 1. 1 Memory 

With the SYSTEM 86, core memory expands from 8K to 128K words in modular 
8K word increments. Cycle time is 600 nanoseconds. The entire memory system is 
addressable and alterable in bit, byte, halfword, word, and double word quantities.. 
Individual memory locations can be addressed without the use of base registers, index 
registers, or other modifications. 

Memory Byte Parity - A parity bit stored in each 8-bit byte permits selective 
replacement of individual bytes with no added time penalty for parity recomputation. 

Word Slicing - Permits reading and writing of individual bytes or half words in 
any memory location. 

Power Fail/Safe Feature - Prevents modification of memory data, either in 
the event of power failure or during normal turn-on and tuxm-off. 

Multiple Memory Ports - Memory accesses for I/O and program execution are 
performed during the same memory cycle. 

Memory Page Protect - Gives the user program control over access to selectable 
pages of memory, areas of memory can be kept private for individual user's programs. 

C. 3. 1. 2 Pi’ocessor 

The central processor performs arithmetic, logical, comparison, and data 


manipulation operations. 




Information Unit - Eight-bit bytes are the standard information unit and are the 
data size used by many external devices. To provide maximum data handling capabili- 
ties there are 15 instructions for operating on bytes, including instructions for 
multiplying and dividing bytes. 

Arithmetic Hardware - Performs fixed-point arithmetic operations on bytes, 
half-words, words, and double words. Boolean load/store, and compare instructions 
are also provided for these data sizes. Standard floating-point hardware performs 
floating-point add, subtract, multiply, and divide in either word or double word form. 

Instruction Set - Inter-register instructions are executed faster than correspond- 
ing instructions that operate on memory- stored operands. The speed advantage comes 
into play when a routine or macro contains several successive instructions operating 
on the same data values. In place of storing these values in memory, they can be 
stored in a register file; One case where the register file pays off is in task switching 
operations; the system rapidly images the register file in memory. Other features 
include: direct address or entire core memory, indexing, multilevel indirect address, 
and floating-point guard digit for automatic rounding of the least significant bit. 

Registers - For real-time computational efficiency, the Central Processor 
Unit (CPU) has a file of eight high-speed general purpose registers. The register 
file is readily adaptable to arithmetical, logical, and shift operations. Each register 
stores' a full 32-bit word, and can be addressed and operated on by most instructions. 
Such versatility eliminates the need for a separate accumulator and other special 
register reserved for logical and arithmetic operations, 

C. 3.1,3 Interrupts 

The central processor interrupt system automatically schedules service for 
such functions as I/O transfers and the execution of user programs. Each service 
routine is assigned a unique interrupt priority level. The interrupt priority levels are 
structured so that the CPU always attends the most important tasks. 



By adding plug-in modules, the interrupt system can be expanded to include 
128 priority levels. Traps are provided for critical functions like power failsafe/ 
auto start, parity errors, addressing errors, and attempts to execute unimplemented 
instructions. In addition to two interrupts for each of the I/O channels, up to 86 
interrupts are available to tie in with the users special on-line equipment. 

C.3. 1.4 Input/Output 

The SYSTEMS 86 Direct Memory Ihput/Output System handles all data exchanges 
with minimum CPU involvements. It transmits data to and from peripherals at 1. 67 
million transfers per second. The 32-bit data transfer path goes directly to memory 
via a separate memory port. Thus, memory accesses for both program execution and 
I/O transfers are performed during the same memory cycle (i. e. , memory cycles are 
not stolen). 

The format of each transfer can be either a byte, halfword, or word. The total 
volume of data transferred can be shared by as many as 16 Device Controller Channels 
(DCCs). Each DCC services either a multiperipheral device controller, or a single 
peripheral such as a card reader. 

Each DCC has a unique priority level. Users may change priority levels without 
changing a single I/O routine or interrupt routine. Another advantage of the Direct 
Memory Input/Output System is that each DCC can transfer blocks of data concurrent 
with the data transfer activities of other DCCs. Each block transfer can be programmed 
to start automatically at the completion of the preceding block transfer. 

C. 3. 2 Peripherals 

A complete selection of peripheral devices are available for SYSTEMS 86 and 
include the following: 

Paper Tape 

Card Reader 

Card Reader/Punch 

Movable Head Disk 

Fixed Head Disk 
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Magnetic Tape Transports 
Incremental Plotters. 

With SYSTEMS 86 the Acquisition Control System (ACS) for real-time application 
is provided, ACS comes complete with the electronics needed for interfacing and data 
control, including I/O signal conditioning circuits, low- and high-level multiplexers, 
relay multiplexers, digital to analog converters, analog to digital converters, logging 
printers, an interval timer, and power supplies. 

Up to eight separate control subsections, each having a unique priority level, 
can be selected and each subsection can be assigned to job handling of any one of the 
following: 

Up to 1024 high level analog inputs 

Up to 1024 low level analog inputs 

Up to 6432 bit parallel bipolar or contact sense inputs 

Up to 64 single-line pulse accumulator inputs 

Up to 64 16-bit parallel outputs of either pulse or voltage levels 

Up to 64 logging printers. 

C,3,3 System Software 

The SYSTEMS 86 is fully supported with extensive software; for example, 
two operating systems - the Real-Time Monitor or the Batch Processing System - and 
a full range of compatible software processors: Extended FORTRAN IV, Assemblers, 
Utility Programs, Math Library, Hardware Diagnostics, and special purpose programs 
and processors. 

C.3.3.1 Operating Systems 

Batch Processing System - Provides the performance of a mixture of program 
assemblies, compilations, and execution in a job- stack environment. The system is 
designed for compile/ioad/go with no operator intervention. The structure of the Batch 
Processing System allows the addition of memory modules, peripheral, and other 
optional equipment to the hardware system. The system enables the support of real- 
time applications, also. 
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Real-Time Monitor - Provides 64 software priority levels for controlling the 
execution of real-time tasks and batch processing. Multiple tasks can be assigned to 
each priority level permitting up to 225 tasks to run simultaneously. Five methods 
are provided to request the execution of tasks: (1) by hardware interrupt, (2) by operator 
command, (3) on a timed basis via the timer scheduler, (4) by requests from other tasks 
via the monitor services, and (5) by job control directives. Additional features of the 
real-time monitor are as follows: 

© I/O operations from logical files versus specific peripheral devices 
© Overlapping I/O operation with other programs 
© I/O spooling 

© Relocatable loading of task and programs 

© Overlay structures 

© Roliin/roilout to disk storage 

© Mass storage file management 

© System tape generation 

© Global common. 

C.3,3,2 Assemblers 

SYSTEMS 86 offers both a symbolic assembler and a macro assembler for coding 
of real-time application programs. Both assemblers are I/O independent. Both 
assemblers can define FORTRAN- compatible common blocks and are compatible with 
FORTRAN-generated code. 

The macro assembler permits users to nest macros, execute recursive macro 
calls, mid pass parameters onto nested macros. Some of the major features of the 
macro assembler are as follows: 

e Data definition facilities 

© Set of pseudo operations 

© User-defined macro libraries 

© Local labels 
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© Character string concatenation 
© Common definition. 

The symbolic assembler is a subset of the macro assembler. It is designed specifically 
for users who have minimum core requirements and do not provide macro capability. 


C.3,3.3 Compilers 

In three passes, the FORTRAN IV compiler transforms source text into optimized 
object code. The compiler conforms to the American National Standards Institute 
specifications. Several extensions have been added, however, to enhance system 
performance. Some of the extensions are as follows: 

© Inline symbolic coding 
© Mixed- mode arithmetic expressions 

© Array extensions 
© Real-time features 
© Buffered I/O 

© Multiple entry and return. 


C. 3, 3. 4 Support Packages 

The following support packages are provided for the SYSTEMS 86: 

Math Library - Supports both FORTRAN IV and Assembly language. The Math 
Library includes the full set of over 80 subroutines for single - and double-precision, 
fixed- and floating-point, as well as complex and double-precision complex 
calculations. 

Utility Programs - Aid the programmer in debugging and updating his programs 
and converting any media such as tape-to-printer or card-to-tape. 

Diagnostics - Allow users to isolate malfunctions in all major hardware elements 
and peripherals. 
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C. 4 PDP 11/45 

The PDP 11/45 is the newest, largest, and most powerful of the PDP 11 family. 
Every PDP 11 computer is designed to operate as a stand-alone computer and as an 
element in a multiprocessor system. The PDP 11/45 is based on the unified, 
asynchronous UNIBUS data path. The central processor, its memory, and all 
peripheral devices attach to this one high-speed bus. As a result of the unified bus 
structure, PDP 11 multi-processor systems require only one physical linkage between 
two processors; a single hardware link that provides access to both memory and 
peripherals, 

C, 4. 1 Architecture 

The PDP 11/45 is a 16-bit computer. It is designed as a computational tool for 
high-speed real-time applications and for multi-user, multitask applications re- 
quiring up to 124K words of addressable memory space. It will operate with solid- 
state and core memories. Its major features are choices of 300 or 450 nanosecond 
solid state memory, a floating-point processor and a memory management scheme that 
provides multiprogramming, 

C, 4, 1.1 Memories 

Three types of memory are available for the PD P-1 1/45: 
o Solid-State: 

Bipolar memory with a cycle time of 300 nanoseconds 
MOS memory with a cycle time of 450 nanoseconds 

® Core*. 

Magnetic core memory with a cycle time of 850 nanoseconds, access 
at 350 nanoseconds (450 nanoseconds at the UNIBUS). 

Any system can be expanded from the basic 4,096 words to 126,976 words in 
increments of 4, 096 words. The system can be configured with various mixtures of 
the three types of memory. 
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To provide overlapped operation, the solid-state memories are dual -ported, 
allowing each memory bank to interface to both processor and the UNIBUS. This 
structure allows peripherals to be communicating with one bank of solid-state memory 
or core at any time that the processor is operating with the other. Solid state memory 
can be expanded to 32K words of MOS, 8K words of bipolar, or a combination of 16K 
words of MOS and 4K words of bipolar. Core and MOS can each be interleaved. 

Memory byte parity is optional. 

The PDP 11 /45s memory management facility allows memory to be expanded 
from 28K words to a total of 124K and in a multiprogramming environment, it re- 
locates and protects user program segments in memory. To perform these functions, 
the system provides mapping of the user’s virtual address into a physical machine 

address. This relocation function takes a total of 90 nanoseconds. 

\ 

C.4.1.2 Processor 

\ c 
* 

The system can be configured as a single processor or, for additional capability, 
as part of a multiprocessor network. Because solid-state memories are dual-ported, 
the single processor configuration permits overlapped store/feteh memory operations 
for maximum throughput. In the dual processor system, the second port of solid-state 
memory is connected to a second UNIBUS, which serves as the data bus for a second 
processor and its peripherals. In this dual processor system, solid-state memory is 
shared and acts as a communication path between the two processors. 

Floating Point Processor - Allows users to perform integer- floating conversions 
and floating point arithmetic operations. The processor operates with single and double 
precision numbers that provide 7 or 17 decimal significant digits. 

Hardware Stacks - Provides the PDP 11/45 with fast temporary storage for 
frequently used data and for storage of program information during interrupts and 
subroutine calls. 
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Instruction Set - Facilitated by the UNE3US architecture, the instruction set 
allows the same instructions that address memory to directly address devices 
without having to transfer the data to a general register. This reduces to a single 
class of instructions, which simplifies system programming. The instructions operate 
on words, bytes and bits in both single and double address formats. For programming 
ease, and core efficiency, the instructions include hardware multiply and divide, 
optimize coding of loops, calling of reentrant subroutines, dynamic priority interrupt 
servicing, communications between processor modes, and operation mode setting, 

Registers - For real-time operation, the PDP 11/45 contains 16 general registers 
which can be used as accumulators, index registers, auto- increment or auto-decrement 
registers, or as stack pointers for temporary storage of data. One set of registers, 
numbered zero, provides context switching for real-time data acquisition while a second 
register set can be used concurrently for general programming functions. 

Automatic Power Fail and Restart - When the system senses a power brownout 
or failure, standard features of the PDP 11/45 trap the processor to a power fail 
routine. Upon power return, the processor is initialized and trapped to a new location 
which branches the machine to a user-programmed restart routine, 

C.4, 1,3 Interrupts 

The PDP 11 /45s interrupt structure provides four hardware interrupt levels, 
each of which can handle multiple devices. The priority of a device on a particular* 
level depends upon its proximity to the central processor. 

The interrupt structure gains additional speed and power through the PDP 11 
vectored interrupt scheme. When a device interrupts, it provides a vector to its own 
service routine. Without vectored interrupts the system would have to poll all devices 
to determine which one caused the interrupt. In addition to hardware priorities, 
the PDP 11/45 provides seven levels of software priorities so that the program, as 
well as hardware, can assign priorities and generate interrupts. 


C-16 



C.4. 1.4 Input/Output 

The PDP 11/45 provides for direct access to memory. Direct memory access 
devices are attached to the UNIBUS. DMA devices have maximum priority, thus 
allowing data storage or retrieval at memory cycle speeds. 

Direct memory or direct data transfers can be accomplished between any two 
peripherals without processor supervision. These nonprocessor transfers, called 
NPR level data transfers, are usually made for direct memory access {memory to/ 
from mass storage) or direct device transfers {disk refreshing a CRT display). 

In the PDP 11/45 an NPR device can gain bus control in 3.5 microseconds or less 
(depending on the number of devices on the UNIBUS) and can transfer 16 -bit words to 
memory at the same speed as the effective cycle time of the memory being addressed. 

C. 4, 2 Peripherals 

A full line of peripherals is available. Many of the peripherals are designed 
and manufactured by DEC, DEC also provides a selection of clocks, switches, and inter 
faces for specialized data acquisition or communication applications. A list of peri- 
pheral options follows: 

Teletypes - 

High-speed papertape reader punch 

Card reader 

High-speed line printer 

DEC terminal display 

Storage display 

Oscilloscope 

Point plot display 

DEC pack disk cartridge system 

DEC disk system 

Disk and control 

DEC pocket-size tape 

DEC magetic tape 
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C. 4, 3 System Software 


The PDP 11/45 is fully supported by system software which includes operating 
systems, compilers, and communications and real-time monitors, 

C. 4. 3. 1 Operating Systems 

RSX 11 D is a real-time, event-driven, disk -based operating system which runs 
on both the PDP 11/40 and PDP 11/45 computers to provide real-time foreground 
processing and a background area for job development or computation. The S 3 ^stem 
features; 

© True multiprogramming for an unlimited number of tasks with 
reentrant l/O handlers and FORTRAN libraries 

© Real-time task scheduling with 250 priority levels 

© Batch or background processing 

© Memory management 

q System protection 

© Device independence, automatic queuing, and spooling 

© File management, 

' Resource Time- Sharing System (RSTS) - A time- sharing executive that allows the 
PDP 11/45 to handle up to 16 interactive users simultaneously. File protection is 
provided as is support for multiple disk file processing for each user. 

DOS - Provides management of disk storage (sequential and random access), an 
on-line editor and an on-line debugging program. The DOS executive is modular, which 
enables users to management of core storage by keeping the modules core resident or 
swapping them into core when they are needed. 



C. 4. 3.2 Assembler 

PDP 11/45 offers an assembler with full macro capability. The assembler 
produces object modules that may contain absolute and/or relocatable code. Separately 
assembled object modules may be linked with the aid of global symbols, 

C.4, 3.3 Compilers 

PDP 11/45 provides FORTRAN IV that meets ANSI requirements for software 
capability and the BASIC- PLUS interactive language, which enables the user to have access 
to the standard features of the BASIC language as well as such extended language 
features as matrices, strings, files, etc. 

C. 4. 3. 4 Support Software 

The computer languages are supplemented by an on-line editor and an on-line 
debugging program that facilitates program development via the console terminal. 

Utilities also include a complete file package, a linking program, and a package of 
commonly used math and FORTRAN subroutines. A library program facilitates the 
creation, modification, deletion and listing the contents of libraries. 

C. 5 SIGMAS 

This section addresses the characteristics and capabilities of the Xerox 
Corporation SIGMA 9 computer. The proposed TDRS computer configuration of 
Xerox Corporation equipment consists of two SIGMA 9 computers to provide the 
processing and computing capabilities, a Xerox 530 computer that functions as the 
system monitor, and system control units to service the downlink equipment. 

C.5,1 Architecture 

A SIGMA 9 consists of one or more central processing units, core memory, 
and one or more input/output processors (each may have one or more subchannels, 
device controllers, and I/O devices). 
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The SIGMA 9 computer provides standard features like independent, 
asynchronously-operated Input/Output Processors (IOPs) and a memory architecture 
that allows multiple, simultaneous accesses to memory, instruction-look ahead, a 
2 2 4- level external priority interrupt system, storable interrupt conditions, overlapped 
instructions through memory interleaving, floating-point hardware, and options like 
memory- to- memory- move, 

C, 5, 1, 1 Memory 

SIGMA 9 core memories use a 33-bifc word (four 8-bit bytes, plus a parity bit) as 
the basic unit of information. It is also addressable by 8-bit bytes, halfwords and 
doublewords. All memory is directly addressable by both the CPUs and IOPs. The 
SIGMA 9 core memory has a cycle time of 900 nanoseconds. The following are the 
features of the SIGMA 9 core memory: 

Memory Capacity - Expandable from a minimum of 65, 536 words to a maximum 
of 524, 288 words. 

Memory Organization - Core memory is divided into banks. A memory bank, 
the smallest section of memory that can be independently accessed by a processor, 
consists of 16K words. Two banks of 16K words each, sharing common port logic, 
comprise a memory unit. This arrangement of memory banks into units provides the 
SIGMA 9 memory with two-way interleaving between 16K banks within a unit and four- 
way interleaving between the four 16 K banks of two units. 

Memory Protection - Features clocks and keys for operation protection, the 
system has priviledged instruction logic that permits dual- mode (Mas ter /Slave) 

i 

operations. 

Asynchronous Memory Design - Allows a memory cycle to be initiated at any 
time, yielding a maximum rate of over 1, 100, 000 cycles per second in each memory 
bank. 
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Multiple Ports - Permits the simultaneous access of different memories by 
different process sorts. Each core memory contains two memory ports as standard 
with each port capable of connection to a separate memory bus. Optional ports may be 
added up to a maximum of 12 ports per memory unit, 

C.5. 1.2 Processor 

The SIGMA 9 Central Processing Unit (CPU) consists of an arithmetic and control 
unit and one group (expandable to four) of 16 general purpose registers. The CPU 
performs arithmetic and logical operations; sequences and monitors instruction 
execution; and controls the exchange of information between core memory and other 
parts of the system. 

Registers - Instead of conventional accumulators or index registers, SIGMA 9 
provides general purpose registers. A SIGMA 9 CPU can contain up to 64 of these 
32-bit registers arranged in blocks of 16. 

Addressing - The SIGMA 9 addresses all of memory directly without the need 
for base addressing. All addresses are 17-bit real word addresses. 

Instruction Set - For ease of use, SIGMA 9 utilizes a single instruction format. 
SIGMA 9 provides 100 major instructions from which a great many different operations 
result, all within the single format. The instructions include floating point operations, 
byte- string manipulation, absolute and complement loads, selective and multiple 
register operations, and a variety of shift operations. 

Control and Protect Features - Aimed at controlling and protecting the system 
environment, including; 

e Master/Slave states 

e Priviledged operations 

© Condition code for dynamic decision making 

e> Program status doublewords for program state preservation 

© Traps for automatic and recovery from programming errors 

© Real-time clocks 
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@ Watchdog/ timer for the prevention of program faults 

© Power fail/safe. 

C.5. 1.3 Interrupts 

The SIGMA 9 priority interrupt system was designed with a hierarchial structure 
of importance considering up to 224 levels of external interrupt are available. An 
external stimulus is associated with a particular interrupt level. Each level has a unique 
address assigned in core and a unique priority. 

C . 5 . 1 , 4 Input/ Output 

In the SIGMA 9 system input/output operations are primarily under the control of 
one or more Input/Output Processors. This allows the CPU to concentrate on program 
execution, free from the time-consuming details of I/O operations, SIGMA 9 IOPs 
require only an initializing sequence from the central processor; once initiated, each 
IOP performs independent of the CPU and without the need for further intervention 
performing one or several separate functions as required. 

Up to 11 IOPs can be incorporated into a SIGMA 9 system. These may be 
multiplex IOPs (MIOPs), for use with standard speed peripheral devices, including 
-medium speed random access disks (RADS); high-speed RAD IOPs (HSIOPs) for use with 
XDS high-speed RAD storage units (head-per-track disk storage devices for very fast 
secondary storage); or special purpose units. The interfaces between the CPU, core 
memories, and IOPs are generalized so that no redesign of existing interfaces is 
necessary to provide new types of I/O capability; thus the user can add new types of 
IOPs to his system in the future. 

C.5, 2 Peripherals 

XDS offers an extensive array of System Interface Units (SUIs) which can be used 
with all SIGMA computers. These standard modular units connect analog and digital 
devices to the computer while exploiting the computer input/ output features. / 

System Interface Units are handled in the same manner as XDS peripheral devices and 
they have standard system support software. In addition, the following' standard 
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peripheral equipment is offered for the SIGMA 9 computer: 

Rapid Access Data Units 

Removable Disk 

Magnetic Tape Units 

Graphic Displays 

Card Equipment 

Graph Plotters 

Line Printers 

Keyboard/Printers 

Paper Tape Equipment 

Data Communications Equipment 

Remote Batch Terminal 

Peripheral Equipment Switches 

Channel Interface Units. 

C.5.3 System Software 

A variety of software packages - operating systems, language processor and 
application-oriented programs - are available to SIGMA 9 users. 

C. 5. 3. 1 Operating Systems 

Three operating systems are provided: 

Time Batch Monitor (RBM) - For concurrent real-time and batch processing when 
critical real-time response is essential. RBM consists of three major software 
elements: (1) the RBM monitor, including overlay loader and file management 
facilities, (2) a variety of language processors with associated libraries and (3) 
system generation and system load programs. 

Real-time applications have priority access to foreground system resources. 
Resources that are intermittently available during processing of real-time application 
are used by the background. 
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Batch Processing Monitor (BPM) - BPM is a general purpose operating system 
offering a wide variety of services and processors under various operating modes. 

© Local batch processing 

9 Remote batch processing 

© Real-time tasks that require priviledged services 

© Peripheral processing 

© System services/control commands, loading, I/O procedures, check point 
service, overlay service, file management service. 

Batch Time Sharing Monitor (BTM) - Provides all of the batch and real time 
functions and sex'vices of BPM, while offering a number of additional features for the 
support of time- sharing operations as follows: 


© Three modes of batch service access 
© Full compatability between on-line and batch modes 
© Complete management control of operations 
© Real-time capability. 


C.5, 3.2 Assemblers 


The assemblers available under the RBM, BPM and/or BTM operating systems 
are described as follows: 


META-SYMBOL - A high-level, two-pass symbolic assembly language and 
processor that permits parameter to be tested and variable code to be generated during 
assembly based on the results of the tests. 

MACRO- ASSEMBLER - A subset of META-SYMBOL is a high-speed assembly 
language operating in the batch background mode under RBM. It permits programs to 
be assembled in the background concurrent with foreground and real-time operations, 
and provides an optimum processor for the generation of machine object code. 
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C. 5. 3. 3 Compilers 


The following compilers are available under RBM, BPM and/or BTM operating 
systems; 

FORTRAN IV- H - Enabling on-line terminal users to compile a FORTRAN source 
program file, generating an object program file. The source file can be created directly 
on-line with the FORTRAN subsystem, via the on-line EDIT subsystem, or entered 
through the batch system. 

Extended FORTRAN IV - This one-pass compiler is designed for compatibility 
with the compilers for many other computers. It includes a number of core- con serving 
features such as generation of reentrant programs. 

BASIC - Utilizes the highly extended XDS version of the original Dartmouth 
BASIC language. 

C. 5, 3, 4 Support Packages 

Assembler Service - To let terminal users assemble source text files. 

Loader Subsystem - Which loads XDS standard object language programs from 
specified element files. 

Debugging Service - Using the DELTA interactive debugging package, 

FERRET Subsystem - Permits the on-line user to obtain information about his 
permanent files and to manipulate files. 

MANAGE - A generalized file management system. 

General Purpose Discrete Simulator (GPDS) - A transaction flow-oriented 
simulation language. 
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C.6 Xerox 530 


The Xerox 530 computer is proposed as the system monitor computer of the 
proposed Xerox Corporation computer configuration to support TDRS. 

The Xerox 530 is a microprogrammed, 16-bit computer offering such hardware 
features as multiple access paths to memory, up to two asynchronous I/O pi'ocessors, 
six general purpose registers, optional floating point hardware, and instructions for 
manipulating portions of a computer word (field addressing). 

C.6.1 Architecture 

There are three main busses in the system: the memory bus, unit memory bus, 
and the internal Direct Input/Output (DIO) bus. The memory bus connects memory to 
the unit memory bus and the Central Processor Unit (CPU). The unit memory bus is 
used by all units that require direct access to memory with the exception of the CPU. 
The internal DIO bus pi’ovides control intercommunication between the CPU, interrupt 
system, external interface feature, Input/Output Processors (IOPs) and Direct Memory 
Adapters (DMAs). 

Typically the external interface feature provides for low speed, intermitted data 
transfers. The IOPs handle the bulk of medium speed transfers. DMAs handle high 
speed direet-to-memory transfers. 

C.6. 1.1 Memory 

The Xerox 530 memory is word-oriented with each word consisting of 16 bits plus 
2 parity bits. Memory cycle time for a 16 -bit word is 800 nanoseconds, memory can 
be field expandable from 8K to 64K words in a single bank. The following are the 
significant features of the Xerox 530 memory system: 

Unit Memory Bus - Provides four memory access paths in addition to the CPU 
memory path. Memory is addressed identically through all paths and one memory 
access may be initiated during any instant of time. 
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Memory Protect Feature - Allows the monitor to prevent a background program 
from accidentally destroying the foreground or resident monitor area. 

Power Monitor Feature - With this feature, program and interrupt status can be 
saved through the operating system. The power monitor is a standard feature that 
detects the loss or restoration of system power and causes either a power-off or 
power-ori interrupt to initiate program save or restore operations respectively. 

Micro-diagnostics - Diagnostics are permanently stored in read-only memory 
and are initiated automatically as part of the initial loading sequence. 

C.6.1.2 Processor 

The following are the significant features of the Xerox 530 CPU: 

Registers - The six general registers provide for single- or double-precision 
accumulator; pre -indexing (base addressing), postindexing, (double indexing), subroutine 
linkages, program address, and temporary storage. 

Real-Time Clocks - Two real-time clocks permit programs tied to interrupt to 
be initiated and timed on a different basis. 

Instruction Set - The extended arithmetic feature standard with the Xerox 530 
contains the multiply and divide, double precision capability, multiple register 
instructions, and general register instructions. Multiple register instructions can 
handle up to six sequential registers. The general register capability allows any 
of the six general registers to act as the accumulator. When executing, single-precision 
load, store, add, subtract, compare and logical. 

C.6. 1.3 Interrupts 

The Xerox 530 can activate (trigger) any interrupt level with a single instruction. 
This feature is especially useful when it is necessary to write programs to interact with 
special equipment that uses interrupts, before that equipment is actually available since 
it allows small routines to realistically simulate the special equipment for purposes of 
program debugging. 
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Interrupt triggering is useful in establishing a hierarchy of interrupt responses 
to a given event. A high priority routine can capture system resources to process 
the time critical function of its application using a high priority interrupt. 

Sixteen standard interrupts (10 internal and 6 external) are provided with the 
system. These are expandable into groups of 12 each up to total of 40. Each external 
interrupt can be individually armed/disarmed and enabled/disabled under program 
control . 

C . 6 . 1 . 4 Input/Output 

Input/output for the Xerox 530 is facilitated by Input/Output Processors and 
Direct Memory Adapters, that are described as follows: 

Input/Output Processor (IOP ) - lOPs are capable of high volume data I/O 
operations, simultaneously with computing operations. Up to two lOPs operate independ- 
ently of the CPU communicating with memory through the unit memory bus. 

The IOP is composed of channels that operate independently with one another and 
the processing unit in providing data transfer between various types of I/O devices and 
memory. Each channel instructed by its own I/O control doubleword, can govern data 
transfer operation between main memory and a selected I/O device. IOP No. 1 is 
capable of simultaneously handling 16 channels; IOP No. 2 (Optional) handles an 
additional 12 channels. 

Direct Memory Adapter (DMA) - A DMA (optional) is 16 -bit direct memory 
interface providing data interchange between the user’s external devices and the Xerox 
530 main memory at 625, 000 words per minute for specialized data acquisition applica- 
tions. It consists of data lines, parity, address lines, and control lines. Each DMA 
(maximum of two) uses one of the memory access paths on the unit memory bus. 

C.6.2 Peripherals 

x , / 

A wide selection of off-the-shelf components are provided, meeting the require- 
ments for many types of special purpose systems without the need for special engineering. 
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System Interface Units (SIUs) which connect analog and digital I/O devices to the system, 
are designed to take advantage of the advanced Xerox 530 input/output structure. 

A complete selection of diagnostics and handlers is available to support SIUs. 
Diagnostic software includes analog calibration and checkout programs, as well as 
input/output handlers. These handlers are written in re-entrant code and are FORTRAN 
callable. 

Standard SIUs available for the Xerox 530 system include: 

Analog Input Controller 
Analog Output Controller 
IOP-to-DIO Adapter 
Digital I/O Subsystem 
Analog and Digital Adapter 
Frequency Control Sub system. 

A range of standard and special purpose peripheral equipment is offered as listed 
below: 

Rapid Access Data (RAD) Files . 

Magnetic Tape Units 
Card Equipment 
Line Printers 
Keyb o ar d/ P r inte r s 
Paper Tape Equipment 
Graph Plotters 

Data Communication Equipment 
Removable Disk Storage 
Xerox Cartridge Disk, 

C.6.3 System Software 

Xerox 530 programming systems are compatible with that of the Xerox Sigma 3. 
Xerox -supplied programming systems automatically perform many routine program- 
writing functions. 


C-29 



C. 6. 3. 1 Operating Systems 


Users have the choice of two operating systems: Real-time Batch Monitor (RBM) 
and Basic Control Monitor (BCM). 

RBM - Performs multitask foreground operations concurrent with batch back- 
ground processing. A disk -base operating system, RBM, offers the user a full 
complement of processors and services. Certain basic characteristics of RBM 
contribute equally to both real-time and background (batch) operations. 

© File management capability 
© Fully overlay services 
© System generation 
© Device -independent input/output 
© Debug package 
© .Core resident library 
© Memory protect feature. 


BCM - Supports the minimal Xerox 530 hardware configuration. BCM provides 
centralized services for input/output, interrupts, clocks, etc. It allows the user to 
perform real-time foreground processing and background batch processing concurrently, 
making use of the memory -protect integrity of the foreground real-time task and 
Resident Monitor by preventing a background job from modifying protected memory. 

BCM includes: 

© A resident, absolute program loader 

© Relocatable loaders 

© Operation-communication facility 
© Debug facility 

© Library of mathematical routines 

© A utility package of media copy routines and test editors. 


C.6.3.2 Assembler 

A MACRO assembler (extended symbol) is available. It permits programs to be 
assembled in the background concurrent with foreground and real-time operations. 
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C.6.3. 3 Compilers 


The compiler provided for the Xerox 530 Systems is American National Standard 
(ANS) FORTRAN IV that generates reentrant code. 

C.6.3.4 Support Packages 

RPG, SORT, scientific subroutines, debug package, test editors, and media copy 
routines are provided for the Xerox 530. 
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C. 7 XEROX SYSTEM CONTROL UNIT 


This paragraph addresses the characteristics and capabilities of Xerox Corpora- 
tion's System Control Unit (SCU). This SIU is proposed as part of the Xerox Corpora- 
tion configuration for TDRS to service the downlink equipment. 

The SCU is a microprogrammed data processor, designed to interface to a 
central computer, peripheral devices, many kinds of line protocol, and analog de- 
vices. Microinstruction sequences control the flow of data within the machine and 
provide logical and arithmetic manipulation capabilities. 

With the addition of a translator function, a computer instruction set can be 
emulated. Also, the generalized three -bus structure of the machine enables other 
functions to be added. 

C.7.1 Architecture 

The SCU consists of input/ output interfaces, general registers, microcontrol 
elements, arithmetic logic unit, and scratch pad/main memory. These elements 
are connected between three 16 -bit data buses that are used in common. 

The input/output interfaces are "plugged" in the SCU directly to the three buses. 
Up to 128 devices can be added in this fashion. 

C.7.1.1 Memory 

The optional scratch pad/main memory provides up to 1024 words of high-speed 
storage at the system cycle, rate (350 nanoseconds) and from 4096 to 65, 536 words of 
slower memory storage at a 700 nanosecond cycle rate. The scratch pad can be used 
for intermediate storage beyond the limits of the general registers or for other 
purposes. The main memory can be used to store data, results, micro-instructions 
awaiting transfer to a variable control memory, or macro instructions in the emulation 
mode of SCU operation. 
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Three types of control memory are provided: 

Programmed Read-Only Memory, (PROM) - Provides 256 to 1024 32-bit words 
per module in 256-bit increments of programmed read-only memory for microinstruc- 
tions. Locations are provided for up to four modules (4096 words); parity checking 
capability is optional. At least one PROM module must be included in each configura- 
tion, unless EAROM plated-wire control memory is used. 

Random Access Memory, (RAM) - Provides 256 32-bit words per module of 
read/write random access memory for microinstructions. Locations are provided 
for up to four modules (1024 words); parity checking capability is optional. 

Electrically Alterable Read-Only Memory (EAROM) - Provides 1024, 2048, or 
4096 32-bit words of electrically alterable (off-line) read-only memory for micro- 
instructions. Parity checking capability is included. This type' of memory cannot be 
intermixed with PROM or RAM options. A portable or rack-mounted load box is re- 
quired to alter the EAROM off-line. 

Field Verification Memory - Provides 256 32-bit words of preprogrammed read- 
only memory that performs a go/no-go quality check of the basic unit, control memory, 
scratch pad, and main memory, but not of input /output modules, translators, or 
maintenance control panel. 

C. 7.1.2 Processors 

The SCU basic unit comprises the following standard elements: 

Microcontrol Elements - Include the microaddress register, control memory, 
and microcontrol register. The microregister provides the microaddress of the 
location in control memory of the next microinstruction. The control memory holds 
a sequence of microinstructions. The microregister holds the current microinstructions 
while it is being executed. 

Arithmetic Logic Unit - Is capable of 32 arithmetic or 16 logical operations, 
taking its two operations from the A and B Busses and placing the results in the C Bus. 
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General Registers - The eight general registers can be interchangeably used as 
accumulators or index registers, to store intermediate results, or to move data from 
the C Bus to the A or B Bus. 

Micro-Instructions - The 32-bit micro instruction is divided into a number of 
fields that control all the operations of the machine. They direct the flow of data 
through a variety of paths. Incoming data from the input/output bus, for example, 
can be routed directly to scratch pad/main memory or can first be operated on in 
the arithmetic logic unit. Results from the arithmetic logic unit can be transmitted 
immediately via an input/output register to the input/ output bus or can instead be held 
in a general register pending further manipulation with the machine. Similarly, 
information from scratch pad/main memory can be routed to the input/ output bus or a 
general register. 

Translator - Translates a macroinstruction of a computer instruction set into a 
vector (microaddress) and argument that accesses the first of a series of microin- 
structions that may be required to implement the macroinstruction. With each 
translator a control memory containing emulation firmware and input/output modules 
are required, as well as scratch pad/main memory in sufficient size to run the desired 
program. 

C.7.1.3 Interrupts 

Two interrupts provide high-speed data transfer, both in or out, within the cycle 
time of a single microinstruction (350 ns). 

A general multiplexed internal structure is provided. Internal state and the 
micro address of the microinstruction are nested (up to 16 times in a push/pull stack) 
permitting the controlled microprogram to branch to a higher priority task, then 
return to a lower priority task. 

C, 7,1.4 Input/Output 

The generalized input/output structure and the corresponding microfields permit 
the machine to interface a variety of devices and buses through either standard or 
custom-designed input/ output modules. 
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External connections are made with up to four 14 conductor cable-connector 
assemblies on the front edge of each input/ output module. 

C. 7. 2 Peripherals 

Locations are provided in the basic chassis to install up to six input/output 
modules. Additional input/output modules may be installed in an I/O expansion 
chassis. A variety of input/output interfaces are provided for use with the SCU. 

Teletypes 

High-Speed Paper Tape 
Maintenance Control Panel 
Disk 

\ 

Analog-to-Digital converter 
Digital -to -Analog converter 
Digital Input/ Outputs 
Communication Modems 
Video Display. 

C. 7. 3 System Software 

A number of software packages may be used with the SCU as follows. 

C. 7. 3. 1 Operation S} r stem 

Bootstrap Loader - Available in two forms; teletype and high-speed paper tape, 
both of which forms consist of nine microinstructions. If control memory RAM is in- 
stalled, these microinstructions can be loaded manually from the maintenance control 
panel. Alternately, the bootstrap load can be permanently located in fixed control 
memory RAM. 

Loader - Loads paper tape data from an A SR 33/35 teletype into central memory 
RAM or MAIN memory. 

Teletype Driver - Interrupt driven and handles a telet}T)e in full duplex or half 
duplex mode of operation. 
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C.7.3.2 Assembler 


The Micro Cross Assembler enables a user to prepare microinstructions in 
a simplified manner using mnemonics instead of binary digits. Each microinstruction 
takes the form of a command represented by a mnemonic, followed by several arguments. 
Approximately 60 commands are available in this assembler. 

C. 7. 3. 3 Support Packages 

The SCU Debug Program enables the user to test and debug a microprogram on 
the SCU. It consists of approximately 650 words in control memory, loaded from a 
paper tape reader by means of the Loader Program. Alternately, it could be stored 
in fixed control memory ROM. Approximately 256 words of scratch pad/ main memory 
are needed. 

The Debug Program enables the user to run the microprogram being tested 
under keyboard control. It provides the means to run to a specified breakpoint and 
to examine status, registers, and memory at that point. 
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